I remember when Slack in a Chrome tab committed 3-4 GB. Sounds like they've made improvements.
Standalone client and its helpers are sitting on ~800MB committed on my install of High Sierra. Might be worth a shot.
Standalone client and its helpers are sitting on ~800MB committed on my install of High Sierra. Might be worth a shot.
A big part of why this occurs is Electron. Same with any app that's basically a browser app: memory usage is out of control relative to what the application does.
Case in point: https://arcade.ly/games/starcastle/ (disclaimer: I wrote this). Uses 284MB, for a version of a vector arcade game from 1980. Same issue with my version of Asteroids too: https://arcade.ly/games/asteroids/. Some of this is down to the idiotic way the Web Audio API handles compressed audio, but with Asteroids I have to pre-render a lot of images because canvas 2D performance isn't that great with drawing primitives. Even excluding these issues, and allowing for several canvas layers at 1366 x 768 x 32 bits per pixel, double-buffered, and the thing still seems to consume quite a bit of RAM.
Welcome to the wonderful world of JS/CSS/HTML5 apps.
RAM prices have plateaued due to production shortages in the past few years, and many (high-volume) $200 laptops/Chromebooks do not come with 8GB of RAM.
To put this in perspective, I was talking this week to a developer who was essentially apologising to me for a new feature that was going to require insane amounts of memory. This is for a process to handle literally millions of users.
How much memory was it? 3G. Per "instance" of which we need 2... Again, for millions of people.
Want inline pictures? Well, Textual has had that for a long time, irccloud's webUI too.
The amounts of memory that users are reporting for Slack are all several times higher than the entire RAM of the first computer I started using my MSNP client on.
I had to walk 10 miles to school in the snow! Barefoot! Uphill! Both ways!
or
GET OFF MY LAWN!
I think "team software engineering" plays a big part of this, if not even the main reason. When one developer is working on a program, the person tends to be able to keep track of program flow, memory usage in their head and know when things are about to go out of bound, memory shoots up, etc. When you have a whole team working on a huge piece of software, each person is working on one part of it at a time. If your feature grows memory usage by 100mb, it's not a big deal. 20 people doing that, memory usage just grew by 2gb. And then in modern software dev shops, you typically put devs on different features on a weekly basis. (unlike traditional, slow, non-agile development where a person owns a certain module/component and is the expert and works on it for years) When you move to a new feature, you need to pick up on all the details of how it works previously, and you build your stuff on top of it. You don't have context of the really nitty gritty details someone who wrote the original framework thought about. You're going to do something less than ideally efficient. Unfortunately, this is just the way modern team software engineering goes.
Or of course, you can still just say it's a Javascript problem and mock JS; which also has merits.
You're not wrong, but perhaps that's an indication that software companies should use language & environments which enable them to have fewer developers, and enable those developers to keep track of things like resource usage?
Whereas traditionally you would have an engineer responsible for part of the application as time goes by, making sure that it works better while maintaining quality.
Then don't freaking do that. There's no reason to make one huge app with thousands of features that justifies teams of dozens of devs instead of tools that do just one thing (and can be used in a modular way) correctly and nothing more.
Actually, there's one terrible reason: the bigger the app, the higher the wall around the garden and that serves as a justification for the price tag. It's the wrong way of doing things because business. It's exactly the same evil principle as the one which is at work when the sugar or the tobacco industry do their slightly questionable stuff.