Spotify: 1083.7 MB. VS Code: 890.9 MB. Skype: 406 MB.
In the past, I’ve had projects open in VS Code which have caused that number to shoot up into the multi-gigabyte range.
Of course this is all anecdotal but I am pretty sure these numbers come from actual experiences that people are having with Electron apps.
Desktop Spotify has been a resource hungry mess for years now. It used to be known for prematurely wearing out SSDs by constantly writing stuff (cache I think?) to disk.
They were constantly vacuuming some SQLite database.[0]
[0] https://arstechnica.com/information-technology/2016/11/for-f...
On macOS, this will start a ReportCrash process, and end up taking up an entire CPU core just repeatedly crashing, reporting a crash, restarting, etc. It also significantly impacts battery life.
This happens every day for me. It's arguably worse than the SSD-killing SQLite vacuum problem they had.
Weirdly enough, the crashes don't seem to affect any of the app's functionality.
This is absolutely dreadful. I've unfortunately worked in multiple organisations where teams deconstructed their web-based products into microservices for this very reason.
This is just insane.
I've come up with a powershell snippet to fully quit keybase and reclaim ~1GB RAM:
get-process | Where-Object {$_.path -match "keybase"} | Stop-Process
Me too, and you just made me realize, there already exists a system for running Electron apps in a shared instance of Chrome, and it's installed on almost everyone's computer! You just... open the web version, in Chrome :)
† I once designed a system that has Electron install an Erlang release to the client, register it as a service, and start it. The Erlang node runs a locally-bound web server; the Electron app then visits that web server. All the data-wrangling happens in Erlang land, with Electron just serving as an HTML renderer for the pages coming from the local server. And yet Electron's native side is essential, here, because it ultimately manages the Erlang release (installing it, updating it, etc.) Erlang doesn't have any good tooling for doing client-native stuff on its own; Erlang devs find the whole idea of deploying an Erlang release to a client machine funny.
gps | ? path -m keybase | killThat's ~230 MB. I can get it up to ~275 MB but it seems to return to normal pretty quickly.
It is difficult for me to lay blame at the feet of application developers (assuming they didn’t make the choice to use Electron) when the platform itself is so bad at giving developers ways to manage their apps’ memory usage.
If you want to listen for an event on a global object like `window`, the platform could give a way to do this using a weak reference, but it doesn’t, so you have to make sure to always remember to manually remove the listener yourself or else you’ve just leaked a bunch of stuff.
If you want to load an image, or some other media, the platform could give a way to control the runtime’s internal caches so you aren’t retaining data in memory that you don’t need—but it doesn’t, so you have to hope that the generic runtime memory cache from Chromium is intelligent enough not to retain unimportant things (and, in my experience, it’s not).
This problem has existed in one form or another in every Electron app I’ve ever used. Some are certainly worse than others, but I don’t think I’ve ever seen one come within even an order of magnitude of the memory usage of similar apps written natively.
~60mb memory usage at startup.
Right, I'm convinced.
Try this: open a new Chrome instance; look at its memory usage; then load a bunch of tabs (try an Open All on a bookmarks folder), close them all again, and then look at Chrome's memory usage again. It will have increased.
Chrome isn't leaking memory; instead, it is doing the same thing that an Operating System does: weakly reserving memory to optimistically cache stuff, releasing it again if there's enough memory pressure.
This works okay if you only have Chrome itself running. (Even then, its cache fights a bit with the OS page cache. It's certainly no Postgres, intentionally getting the OS page-cache to do its caching for it.) But as soon as you have two separate Chromium instances running (e.g. Chrome itself, plus an Electron app), then each one is going to try to "optimistically" cache as much stuff as it can, until it runs into the memory pressure created by the other instance caching as much stuff as it can, and so each instance will unload just a bit to let the other one cache just a bit more—back and forth—forever. Together, they thrash memory, and it becomes much harder for them to actually accomplish the "weak" part of "weak reservation", instead ending up hoarding all the memory between them.
This is the pretty much the same problem you see if you try to e.g. run two memory-heavy JVM processes (e.g. ElasticSearch) on the same system. Chrome is just one of the few times you'll see this "recapitulation of memory management within the runtime" effect client-side, rather than server-side.
(Regarding uptime, it's not at all uncommon for Chrome's memory usage to double or even triple overnight. Partially a function of the websites you have open, sure, but also partially a function of Chrome itself).
I have a copy of Slack running that’s using 2GB right now, with no window open.
The solution is for operating systems to inject deliberate back pressure on memory allocations for user-selectable applications to stop them from behaving this way. "No memory for you. Try mallocing smaller chunk. Maybe I grant; maybe I don't. Maybe I just kill -9 you if you bug me too much." This is exactly how I wish my OS would treat web browsers.
[0]: https://lifehacker.com/why-chrome-uses-so-much-freaking-ram-...
[1]: https://stackoverflow.com/questions/53658769/why-vscode-requ...