4 ms·

Being in 2 slack teams use up as much memory as the entire visual studio 2017 does on my machine. It is electron that is the root cause here and it is the same

Being in 2 slack teams use up as much memory as the entire visual studio 2017 does on my machine. It is electron that is the root cause here and it is the same for all electron based apps.

DaiPlusPlus 9y ago
Has anyone published a memory-map - a breakdown of what exactly is in the process' memory space - of these cases where Electron-based applications use orders-of-magnitude more memory than the native programs we used before? Previously I've remarked that high memory usage in web-browsers in itself is not a cause for alarm, and is mostly a good thing because it means the browser is aggressively caching assets so future pageloads will be much faster without needing to load things from disk - however that doesn't apply to Electron-based software because all of the assets are local already so there's nothing to cache that won't be loaded into memory already. So - I'm willing to bet that Electron's high memory usage is probably the JavaScript part - because a native DOM itself, even with all layout information and source assets for images and backgrounds, cannot be more than a few megabytes for even a complicated page (memory usage only shoots up once you start having to download 20MB+ autoplaying video ads). Then multiply the usage overhead of the V8 engine multiple times for the fact that Electron uses V8 to run Node internally, and for each process instance it spawns in the name of reliability - these child processes shouldn't be necessary: "desktop software" shouldn't be running untrusted scripts downloaded from the Internet (WebViews notwithstanding - but they can be isolated already) so adequate testing (and good software design) will ensure a JavaScript snippet will not bring down a process. If they insist on spamming processes, what does that say about their confidence in their code-quality? I'll join-in on the Slack-bashing. I know Slack is very capable and a breath of fresh air compared to Lync/Skype-for-Business, but right now it's consuming 755MB (70% private) between 6 slack.exe process instances on my machine - while the native Windows Telegram client (written in Qt) - with considerably more human-useful-data in-memory (over 200+ groups/channels/etc) is taking up a relatively miserly 133MB (85% private).
- alex-e 9y ago
  There's a new native desktop app for Slack, Skype, WhatsApp, etc: https://eul.im/slack https://eul.im/slack It's only 4 MB and can handle tens of thousands of messages in one chat without lag.
  - staticelf 9y ago
    I would use it but I am afraid that it might steal my accounts. I would feel safer paying for it and I would gladly do that. Now, it just feels like the creator can simply steal my accounts without my knowledge. Windows 10 warns me about the app as well, perhaps because it is not from the Store? I don't really care about size of the application, I just want it to not consume a crazy amount of memory.
    - alex-e 9y ago
      You are right to be cautious. Like the home page says, the binaries are not signed yet, that's why Windows is complaining. Documents are being verified right now, getting a code signing certificate is a slow process unfortunately. There will be a paid option soon. The app sends nothing to the server, only error reports. eul uses 5x less RAM on average.
- turrini 9y ago
  Take Qt Creator for example. I'm now working with 20 medium-sized projects, consuming 305mb of RAM. Without any lag
lsadam0 9y ago
There was a recent post in which the slack team admitted that they build certain dependencies in dev mode in their production release. I wonder how much that is to blame as opposed to electron? In my experience the windows slack client is a dog, while the mac client is a better experience.

Being in 2 slack teams use up as much memory as the entire visual studio 2017 does on my machine. It is electron that is the root cause here and it is the same for all electron based apps.

DaiPlusPlus 9y ago

Has anyone published a memory-map - a breakdown of what exactly is in the process' memory space - of these cases where Electron-based applications use orders-of-magnitude more memory than the native programs we used before? Previously I've remarked that high memory usage in web-browsers in itself is not a cause for alarm, and is mostly a good thing because it means the browser is aggressively caching assets so future pageloads will be much faster without needing to load things from disk - however that doesn't apply to Electron-based software because all of the assets are local already so there's nothing to cache that won't be loaded into memory already. So - I'm willing to bet that Electron's high memory usage is probably the JavaScript part - because a native DOM itself, even with all layout information and source assets for images and backgrounds, cannot be more than a few megabytes for even a complicated page (memory usage only shoots up once you start having to download 20MB+ autoplaying video ads). Then multiply the usage overhead of the V8 engine multiple times for the fact that Electron uses V8 to run Node internally, and for each process instance it spawns in the name of reliability - these child processes shouldn't be necessary: "desktop software" shouldn't be running untrusted scripts downloaded from the Internet (WebViews notwithstanding - but they can be isolated already) so adequate testing (and good software design) will ensure a JavaScript snippet will not bring down a process. If they insist on spamming processes, what does that say about their confidence in their code-quality? I'll join-in on the Slack-bashing. I know Slack is very capable and a breath of fresh air compared to Lync/Skype-for-Business, but right now it's consuming 755MB (70% private) between 6 slack.exe process instances on my machine - while the native Windows Telegram client (written in Qt) - with considerably more human-useful-data in-memory (over 200+ groups/channels/etc) is taking up a relatively miserly 133MB (85% private).

alex-e 9y ago
There's a new native desktop app for Slack, Skype, WhatsApp, etc: https://eul.im/slack https://eul.im/slack It's only 4 MB and can handle tens of thousands of messages in one chat without lag.
- staticelf 9y ago
  I would use it but I am afraid that it might steal my accounts. I would feel safer paying for it and I would gladly do that. Now, it just feels like the creator can simply steal my accounts without my knowledge. Windows 10 warns me about the app as well, perhaps because it is not from the Store? I don't really care about size of the application, I just want it to not consume a crazy amount of memory.
  - alex-e 9y ago
    You are right to be cautious. Like the home page says, the binaries are not signed yet, that's why Windows is complaining. Documents are being verified right now, getting a code signing certificate is a slow process unfortunately. There will be a paid option soon. The app sends nothing to the server, only error reports. eul uses 5x less RAM on average.
turrini 9y ago
Take Qt Creator for example. I'm now working with 20 medium-sized projects, consuming 305mb of RAM. Without any lag

lsadam0 9y ago

There was a recent post in which the slack team admitted that they build certain dependencies in dev mode in their production release. I wonder how much that is to blame as opposed to electron? In my experience the windows slack client is a dog, while the mac client is a better experience.