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