300MB of ram sounds like a lot to me.
What are you storing in memory that is that large?
If I dont use the app for 1 hour will it stop using the memory?
I'm sure that a client like Mutt would use much less but considering that many emails have embed HTML and would ideally use a modern web view to render correctly, how much overhead is there from from using Electron/chromium if you're going to load all of that anyway?
I couldn't find exact figures for MS Outlook but Office 365 seems to require 1Gb as a minimum.
A quick look at the Gmail tab I have open in Chrome seems to be taking roughly 390Mb so this would seem to be an improvement over that.
As a genuine question, what sort of size would you expect for an optimised native app with the same functionality?
For reference, when settled, Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.
I’m tempted to make a FastMail Electron app just to demonstrate that Electron/HTML/CSS/JS doesn’t need to mean slow and heavy (it just normally does).
Later: OK, so on Windows a trivial Electron “just load https://www.fastmail.com/login (and then log in)” app uses ~230MB of RAM. Not what I was hoping for, though it doesn’t surprise me a great deal—Chrome is quite happy to use lots of memory. Interestingly, when I reduce it from 3000×2000 to 1600×1200 (device pixels, it’s a 2× display), it goes down to about 160MB after a bit, and minimised to 180MB or 120MB for the two window sizes. Still very snappy despite this memory usage, though, for FastMail is fast.
> Gmail in Firefox uses 200MB or a bit more, while FastMail uses around 10MB.
Yes, but that’s not a fair apples to apples comparison with his 300mb number. Your looking at the memory used for that tab, not the shared memory used by the browser across tabs. Open Firefox with no sites open and check your baseline memory usage. Add that to the numbers above for a direct comparison.
See my update to the comment. Its memory footprint is greater than I expected. I shan’t pursue it any further at present, I was mostly just curious to get an initial feel for it. Taking it (or something like it) to a polished product is something I’d like to do, but I’ve got other, much more important things to do on FastMail and Topicbox, and I don’t think anyone else in the company feels strongly about it, so it’s unlikely to ever actually happen.
One avenue would be to use a different, more light-weight engine; https://github.com/zserge/webview, for example, can use the local platform’s engine, which is likely to be somewhere between a little and a lot more efficient than Electron/Chrome. Running FastMail with the MSHTML renderer via the Rust bindings for that (DPI scaling issues, but meh), it starts at about 60MB but is easy to get over 80MB with some use. Still quite a lot less than Electron/Chrome.
Maybe you can help me understand the outcry over Electron memory usage, especially on HH. I can't remember the last time I ran out of memory on my laptop or desktop unintentionally. Seems to me battery life and jank should be main areas of focus. You can have a 2GB if you cut CPU usage and typing latency.
Just because you "can" use a bunch of memory without issues now doesn't mean you "should" not make any attempts to cut resource usage whenever possible.
Of course you're right. But why does it seem like memory usage takes precedence over battery life and latency? I may be in the minority, but it seems to me a native app's key advantage over Electron is performance/watt and I don't see how reduced memory usage would help.
I've run out of memory a few times this week on my Linux VM at work, and also at home on the beater laptop I use in the living room. Those are both stuck at 4GB of RAM, though.
On my laptop with 16GB, it's certainly been at least a few months since I've done anything that made it hit swap.
I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits. I probably should have been more clear. I also prefer native apps, which is why I still mostly use Sublime over Code despite the latter's advantages. But it's because of speed and battery life, not memory consumption. If we're going to make a case for native apps, lets at least focus on the biggest pain points, as the proliferation of Electron indicates we're not making an impact.
Battery life's something that I only rarely have to think about. All of my development has always been somewhere with convenient power. It irks me when the CPU's churning along on a process that should be near-idle, though.
> I said "unintentionally" as a hedge for corner cases like VMs where you are likely aware of the limits.
I was aware of the limited memory of the VM, but almost everything I run there is a text-mode application, so it usually doesn't matter. Honestly, I thought that Slack would fit easily in the free memory, but I'm logged into 3 teams, so it ate more than I expected. And it's a spinning rust drive; swapping sucks, and it slows down the host OS at the same time.
It's an avoidable situation; just run Slack under the host's Windows, instead of in the Linux VM. But it remains the case, in my uses, that memory has caused more issues than CPU, and that CPU has caused more issues than battery drain. I don't know why everyone else focuses on memory so much...I perceive my own issues as kind of a corner case.
Actually, that was just from just loading Gmail and letting it idle, a couple of weeks back, not actually using it. A year and a half ago, I recall it being more like 125MB, up towards 150MB as it was used. Gmail hasn’t really changed since then, but the Hangouts widget (which is pretty heavy!) might have, and the browser definitely has (I blame it for most of the increase). I haven’t actually used Gmail since around that time.
For reference, I’m using the explicit/window-objects/top(…) figure from about:memory. This is not an accurate representation of the full footprint, but is close enough.
> considering that many emails have embed HTML and would ideally use a modern web view to render correctly
It might be me, but i prefer them to be rendered incorrectly in a text-only view :-P. I use email since the 90s and so far i do not think i can come up with any case where the HTML in an email was actually useful and not used for fluff (which i do not mind but can do without), branding (which i do not care at all about) or -way way more often- advertisement.
Also almost all HTML mails i've seen come in text-only version too and any useful bits are attachments anyway.
My Outlook (2016) client is using ~300MB right now while displaying a full HTML spam mail (taking one for the team, guys). I wouldn't say I'm a heavy user, but there's shared calendars and mailboxes, OneNote integration, task list etc.
My Claws Mail currently uses 56M, multiple IMAP accounts configured, a few thousand mails, just visited all accounts before measuring. I disabled HTML display, though (most HTML is either spam or newsletter fluff in my experience). Claws is GTK2.
Most of this comes from overhead in Chromium, which currently (the version used by Ivelope) suffers from a few bugs which increases memory usage. I think this will drastically go down as time progresses and new updates of Chromium becomes available
not intended to be a hostile ask here, but do you know any specific bugs to check out?
As a past (very minor) contributor to chromium+webkit I'm curious if there's anything one can do to help, but I haven't kept up with their status in a long time.
Is this even considered a bug by the Chromium team (i.e. is there any indication of plans to fix it, or is this just the image cache working as intended)?
It's a 10 year old project and memory usage has always been fairly high, I don't see any indication of a major focus on reducing it anytime soon.
I don't hate Electron apps or anything, but the ones I already have open are using up enough of my memory that there isn't much left to run more of them. I really do hope this improves in the future though. If not I may just have to buy more RAM.
That's just the base cost of using electron (along with the associated CPU usage). It's terrifying but you get that much usage even if you're not storing anything in memory.
Well that's just not accurate. With our Electron app, the main process consumes 40mb of RAM, with each window using 30mb of RAM, so if you have a windowed app, thats a minimum of under 70mb of RAM (results will differ, our app is quite large).
Yeah, this is realistic. I wish people would stop perpetuating the myth that "That's just how Electron is". It's perfectly possible to write Electron apps that don't automatically hog half a gig of RAM.
That's news to me, and people who make electron stuff tell me they can't get it down below a few hundred mb of memory usage. Can you point me to some resources about reducing that?
Are there any examples of Electron apps that don't do that, though? I've never seen one that didn't like to eat at least a few hundred MB, and most of them seem at least somewhat leaky, too.
I switched from Thunderbird to Gmail because of that; it was quite bad on my laptop. It often started swapping requiring very long waits or a reboot to get back to work.
