The memory is high, but a lot less than Chrome and nothing near what the author is seeing.
Only differences I can see:
- I'm signed into two accounts while the author is signed into 11.
- The author is CEO of a competing messaging platform.
More experiments might be needed here.
I currently have 8 Slack Helper processes, one of which is sticking around 6-7% CPU, but the others are between 0–1%. Slack itself is around 4% (this is without me interacting with it, and with no animated GIFs visible on the screen right now).
FWIW the impact of animated GIFs (including animated custom emoji) is pretty high. Switching to a channel where there's 5 tiny animated custom emoji pushes CPU usage up to 18–20% for Slack Helper, pushes Slack itself up to about 9–10%, and makes my Energy Impact jump to 40–50 (which is insane).
> Matthew O' Riordan is CEO and Co-founder of Ably. Ably is a platform that makes it easy for developers to add realtime messaging... to their applications.
Slack is realtime messaging. Ably is realtime messaging. They are competitors - the only question is how direct.
Slack has a shiny user interface and a bunch of nice enterprise features. It's something you'd have everyone in your company sitting on their machine all day.
Ably is something nobody will ever see. It's an API that underlies other people's applications. Hell, Slack could run on top of Ably.
They're absolutely not competing. You're either misreading or deliberately misleading.
I went to their website, it doesn't seem like that kind of messaging.
> Ably is a realtime data delivery platform providing developers everything they need to create, deliver and manage complex projects. Ably solves the hardest parts so they don’t have to. Our 100% data delivery guarantee offers unique peace of mind to stream data between apps, websites and servers anywhere on earth in milliseconds.
[1] https://slack.engineering/reducing-slacks-memory-footprint-4...
Quotes:
>> This memory footprint increases as the user signs into more teams, as each team runs in its own webview.
>> Each of these teams is running the full JavaScript web application and maintaining and updating the DOM tree as the state of the team changes.
>> Work is underway to fix the underlying factors affecting client memory consumption
>> Exploring running all teams in a shared context to eliminate the overhead of one webview per team.
So then shouldn't it be the same penalty as having 11 pages of Slack open in Chrome? That seems like something not too extreme to me.
Quick responses:
> I'm signed into two accounts while the author is signed into 11.
Yup. Also, see a subsequent update at https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memor.... One of the Slack developers got in touch and confirmed this issue is resolved in beta 2.7.0. I tried it and it is indeed.
> The author is CEO of a competing messaging platform
Ably is not a competitive platform in any way whatsoever. We are a realtime data distribution platform, we have no consumer apps or products you can use, only a low level platform-as-a-service for broadcasting realtime data.
Windows 10 memory compression saves them a lot, but this is absurd, chrome/outlook use roughly 30% of this.
And its just running as a tray icon.
It seems they are trying to hide what they actually use.
2 vs 11 is the precise difference that is important. The author shows that things are more reasonable with 2 accounts.
Without seeming to endorse one platform over another, I've personally seen Slack to be a huge memory, cpu and battery hog. Most of the time, I don't have it open and it hugely hinders my response time to my team. But I can't lug around my 64 GB RAM hackintosh to a coffee shop.
6 Teams on my computer: https://pasteboard.co/GCWfKca.png
Edit: Decided to write a little bit more on this.
> How?
The problem is with Electron shell apps. Electron, while it has made it extremely easy to build a webapp and then ship "native" versions of that webapp across Windows, Linux and macOS, the end product is horribly bloated.
Here are 3 Electron shell apps I am running. They're all bloated. I can't run too many of these at the same time. This laptop has 16 GB of RAM. The other Macbook I have has only 8 GB.
https://pasteboard.co/GCWiqSB.png
- Spotify (music)
- Slack (messaging)
- Dialpad (voip + messaging)
So why is it like that? Electron shell is basically Chromium browser with a much more comprehensive native API that a web browser will allow. The 'Native' UI you're seeing is HTML/CSS and JS.
> Why?
Chromium introduced a very long time ago a process model such that the various subsystems are run in separate processes communicating over IPC. This is very different to a traditional app where you have one process splitting up work over to worker threads.
Chromium used this model to make a solid web browser. Each tab is its own independent process. Each extension is its own process. The rendering work is done in its own process.
Look at the Chrome task manager for example: https://pasteboard.co/GCWmnS9.png
The rationale behind this was that if a webpage caused the browser to crash, it would only crash that one tab and not take down the entire browser. Since processes are isolated into their own virtual memory space, there is much more secure sandbox isolation across processes - so even in the case of a security vulnerability, the process model is fail-safe.
The problem now is that all these processes have a higher overhead. Modern OSes are smart enough to copy-on-write when a process forks (duplicates like a biological cell) - so you're not exactly linearly increasing memory overhead.
Now that these processes are running, they need to communicate with each other. By default, processes are independant and don't share memory across them. So any communication has to be done with IPC(mechanisms for processes to communicate with eachother). This typically happens through Named Pipes, Unix sockets, or even TCP and HTTP. All of this carries more overhead. Running a whole http server to talk just intra-app is absurd and I don't believe any common apps do this. But these types of mechanisms are how these processes talk.
> Solution?
Now back to the concept of the process-model. The isolated process model worked well for browsers. But in the confines of a single app, they don't work well. I would much rather have a single process Electron shell that is able to spawn background threads to do additional work.
Sadly, we're way too far down the other road. I don't know of any effort in Chromium or Electron to retro fit the process model. But if we had one, it would be awesome.
You could also not use Electron shell to build apps. Modern platform frameworks are pretty good. Windows has a XAML + .Net frameworks that is somewhat similar to HTML/CSS/JS. macOS has the fully native Swift and UIKit. Linux...well Linux is good in it's own way too.
But this is really not an option for most start-ups. So don't do that if you're a small company. I would much rather see and use your slow bloated product than to not being able to use it on all platforms.