4 ms·
Speaking as someone with an Ultrabook that had to run Chrome, Outlook, Skype, and various office apps and so forth, this attitude infuriates me. Slack uses 400
by zzalpha 10y ago
Speaking as someone with an Ultrabook that had to run Chrome, Outlook, Skype, and various office apps and so forth, this attitude infuriates me.
Slack uses 400-500MB of memory. That's 15% of my RAM. For a chat application. Every Electron app is in this range. None share a runtime or memory footprint.
Believe it or not, not everyone has 16GB of RAM. This level of inefficiency is utterly inexcusable.
- hollerith 10y agoNot everyone has 16B of RAM, and those that do get worse battery life because that much RAM is a significant part of a laptop's power budget.
- nathan_f77 10y agoNow that you mention it, this is pretty ridiculous: http://imgur.com/a/HyFay http://imgur.com/a/HyFay Code Helper is from VSCode. VSCode, Evernote and Slack are all completely idle right now. I don't think they should be using any memory at all. Especially not over 700 MB. I don't even understand how they could possibly be using that much memory. Is it just memory leaks?
- nextweek2 10y agoThat image means nothing. Apps and the operating system cache lots of different things. If your system was under memory pressure then you'd see it lower. Fact is if the ram it available, an app should cache as much as possible. It has no idea what you'll need next, so better it use a free resource to reduce latency. You cannot think of an app in just terms of the text it handles but also window pixmap data.
- zzalpha 10y agoApps and the operating system cache lots of different things. If your system was under memory pressure then you'd see it lower. There's a problem, though: it doesn't work that way. The size reported by Windows is (if I'm not mistaken) the committed heap size of the program. Unless the application actively surrenders allocated pages back to the OS (and hint: no application does that), that memory is committed. Edit: to add some color: when a program calls malloc, memory is allocated from pools inside the process itself. If no memory is available in the internal pool the allocator will call out to the OS for additional pages (in the Unix world this is a call to sbrk). When free is called, memory is returned to the internal pool but is not surrendered back to the OS and thus remains committed to the process. Actually reducing the committed heap size once again requires an explicit call to the OS (e.g sbrk). Of course it may be swapped out by the OS, but that just means slow disk I/O when that application comes to the foreground or accesses those swapped pages (which presumably contains the precious cached data you refer to). Should the OS use memory to cache transient data? Certainly. OSes typically contain logic to throw away those caches if memory is needed. But applications that do this without intelligently surrendering cached pages back to the OS when memory is low (as an OS does with its own caches) just put that much more memory pressure on the overall system itself. And I've never heard of an application that does this. Certainly I've seen no evidence that Electron is that sophisticated in its memory management, though I'm happy to be proven wrong.
- kk_cz 10y agoDon't know if it's relevant, but that screenshot is from macOS, not Windows. Anecdotally: I am currently running VSCode and Task Manager reports 19,8 MB of memory usage right now (vscode Window being idle, with 6 files opened on Win10)
- slededit 10y agoThe size reported by windows is the private working set. If windows pages out data for non-use it doesn't show unless you add the commit column.