Hacker News Reader

Comment by chrismorgan | Hacker News Reader

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.

View on HN

> 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.

I sought only to compare Gmail with FastMail, to indicate that Gmail is a poor baseline for memory comparisons.

Fair point, I agree there!

How exactly will you cut the fat in Electron? What’s a hello world like?

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).

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.

That's it? My Gmail tabs used to take 2GB (the last time I checked, years ago).

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.

Reply on news.ycombinator.com