7 ms·

Ask HN: Why does Slack App on macOS drain 3GB of memory?

53 points by ktamiola 9y ago

Can somebody explain to me why the Slack app drains >3.5GBs of memory. I am using the version 3.1.0 on 10.10.5 OSX. Am I the only "lucky" user getting such a poor memory performance?

reustle 9y ago
I get around this by using the web client daily (pinned tab in chrome) and open up the desktop app whenever I need to do specifically screen sharing (or just skype). It's not worth the resource headache.
- enraged_camel 9y ago
  Same. The web client has feature parity with the desktop client so I haven’t understood why people bother with the latter.
  - phereford 9y ago
    It does not have complete feature parity. One of the things missing, that is important for me and the team I am on, is the ability to share screens and allow for remote control in that session. That is a Mac App only right now, at least the last time I checked.
    - lojack 9y ago
      Now that screenhero is no more, screen sharing is literally the only reason one of my teams use slack. We use hipchat (not by choice) for the rest of our communication.
  - Cthulhu_ 9y ago
    For me, cmd + tabbing to a chat application is a much better user experience than having to dig through open tabs and/or multiple instances of the browser.
    - reustle 9y ago
      Since it's a pinned tab, it's always number X (3 in my case). CMD+3 inside chrome always takes me there.
- lallysingh 9y ago
  Also Ctrl-F let's you find people in the list of chats.
framel 9y ago
Electron is cancer
- api 9y ago
  We've been making the rounds over all the options over and over again for planning a new app, and we always reluctantly come back to Electron. Qt? No mobile, slower development. Java? No mobile, deployment nightmare, Oracle cooties, and often just as heavy as Electron. Native UI? Out of the question. We don't have anywhere near the resources to develop our app four to five times, implement every new feature four to five times, etc. Others are some combination of immaturity, lack of mobile support, out of date, lack of support for internationalization and accessibility, etc. I agree that Electron is cancer, but until there's a better game in town it's the only thing that could possibly meet our needs. We would pay for a better option, but unfortunately there are probably not enough of us to make another option economically viable. Nobody pays for developer tools so it's an awful market for startups, and a modern UI API with cross platform capability is just too much work for independent open source efforts. My dream would be a really clean cross platform UI library that lets you develop in a language like Go or Rust. UI development in 2018 is a sad state of affairs. It was better in many ways in the 1990s and early 2000s. We had wxWidgets and Qt then and they were decent. Mobile "ruined" it by introducing another incredibly popular UI paradigm that rendered literally everything written to date obsolete.
  - framel 9y ago
    https://www.qt.io/mobile-app-development/ https://www.qt.io/mobile-app-development/
    - api 9y ago
      That's QML, which isn't that different from a browser rendering engine. I'm talking about an actual native UI implemented in native code, not a weird quasi-browser. Of course Qt itself also has quasi-browser features like its style sheet widget styling stuff. If we're going there, why not just use HTML5/JS which has a million billion times more support? Also C++ is not really the best option. I code systems software in C++ but for UI dev it's not quite productive enough. I've worked with large Qt code bases before and no thanks. I suppose if they've modernized it and incorporated C++11 features it might be more bearable, but in the past it was a pretty awful mess of raw pointers and ownership semantics bugs and very very long compile times.
matthewmacleod 9y ago
What I find interesting is that this is now becoming more noticed by other people. We've had a whole bunch of non-tech people at my company start complaining about Slack's sluggish performance, connection drops, the fact that it makes other things on their machine unusable, that kind of stuff. I would like to think this means there will be a bit of a change going forward.
dijit 9y ago
No, that's the default slack experience if you have a lot of teams. I recommend: * Disabling emoji support, especially animated emojis> * Disabling auto-expanding of images (gifs are egregious) * Use compact display * Limit number of channels/groups you're in if possible, surely you don't need all those channels. Doing this curbed my resource usage quite a lot. I don't miss emoji's all that much.
- znpy 9y ago
  I didn't even know all of those things were possible! Thank you!
- cimmanom 9y ago
  Hm, I wonder how much a company's Slack culture affects memory usage. I've never seen it eat more than a few hundred MB, but then my coworkers almost never post GIFs.
deleted 9y ago
[deleted]
totallysnowman 9y ago
This is what you get when you use a full-blown web browser for a simple messaging app.
- deleted 9y ago
  [deleted]
acd 9y ago
FreeBSD an entire operating system runs on about 100MB ram. https://www.freebsd.org/doc/handbook/bsdinstall-hardware.html https://www.freebsd.org/doc/handbook/bsdinstall-hardware.htm...
- znpy 9y ago
  CentOS 7 is roughly the same. For a minimal install (with ssh service and vsftpd), i booted it and flushed the filesystem cache, then ram usage was about 88MB.
  - Koshkin 9y ago
    Heh, the recommended amount of RAM to run Windows 95 was 8MB.
kevingadd 9y ago
I once had it hit 40gb of memory usage. I bought more RAM.
yoz-y 9y ago
A lot of digital ink was spent on this issue. Basically it is due to the fact that the Slack app uses Electron, and thus it is not much more than a Chromium browser with several loaded webpages.
- qaq 9y ago
  VS Code is an electron app
  - maushu 9y ago
    I think they use their own implementation and not electron.
  - jrs95 9y ago
    And it sucks at this too. Just not as badly as Slack or Atom.
onion2k 9y ago
Am I the only "lucky" user getting such a poor memory performance? No, that's very common. For most people Slack's usefulness outweighs it's poor memory footprint.
d3ckard 9y ago
104 MB at the moment. For me at least, Slack really got their shit together sometime last year and improved the issue significantly. I still remember having to restart Slack twice a day, but it ain't issue anymore.
- pointe 9y ago
  Roughly 800MB for me at the moment. 95MB main process, 2 helpers at 50MB and 1 helper at 600MB.
- nellyspageli 9y ago
  Yeah, mine is 122MB at the moment as displayed in the OS X Activity monitor.
  - deleted 9y ago
    [deleted]
  - eddieroger 9y ago
    Continuing the anecdata collection, I'm in the over 1GB club. One instance of Slack, six of Slack Helper, several of which using 200GB of memory, but the biggest being 1GB. Timely thread, since when I sat down this morning and unlocked my computer, I was warned that I'd run out of memory and needed to quit some apps.
    - vog 9y ago
      > several of which using 200GB of memory I really, really hope you mean "200MB", although I honestly wouldn't be surprised if they managed to use 200GB if accidentally started on a beefy server.
- lojack 9y ago
  Would probably help to say how many slack organizations you’re using. I’m on around 6, and Slack almost always takes up a big chunk of memory. I suspect those with less resource usage are in fewer orgs, but it’s hard to say.
- 9y ago
steeve 9y ago
I don't use the app anymore and open it in my browser as a regular tab. Much much better.
- stephenSinniah 9y ago
  I have a MPB 2012 and I purchased a second hand ipad mini2 just so I could handle all my comms through it. Slack was the main culprit for that decision, my computer was basically unusable while running rails with guard + ember + chrome(pivotal tracker) + slack.
makkesk8 9y ago
to be fair, this is not an electron issue as vscode runs fine on all platforms. I don't really want to bash the devs but... Maybe they should take a look at it.
- ktamiola 9y ago
  That's what I have also thought about this!
- w0utert 9y ago
  I have vscode open with a relatively small project here, and excluding the CPP tools it sits at about ~500M used. If I include the CPP tools it's about ~1.5GB. Not as bad as Slack, but I wouldn't call it 'fine' considering that it's just an editor.
  - seba_dos1 9y ago
    For comparison, QtCreator with I'm using right now in one session for a few days, with a full-blown set of C++ tools integrated, consumes 319.1 MB RAM + 140.3 MB RAM for clangbackend. That's less than 500 MB for a complete solution with code analysis, debugger, profilers, form designer and even some QML stuff. Slack, which is idling in the background in just one organization, consumes 22 MB more than QtCreator :P OTOH, there's also a full-blown IRC client Konversation, connected to 2 servers and 42 channels total, consuming 80.6 MB.
- theknarf 9y ago
  Vscode is the best optimized Electron app out there.
- natecavanaugh 9y ago
  VS Code is by far the best optimized Electron app I've seen, but with a total of 5 files open, it will still turn my laptop into a pizza oven on my lap. It, and every JS/Desktop hybrid has so much promise, but my Lord, as a proficient JavaScript junkie that has a deep abiding love for the language, it's not performant. I just can't use either Atom or VS Code for day to day work. PS, Sublime, please support some form of JS plugins, even if that means limiting the API for JS plugins.
unfunco 9y ago
If you're signed into many workspaces, try closing a few.
e12e 9y ago
I quickly abandoned the slack "App", but even dedicating a chromium tab to Slack ended up being absurdly heavy. So I've finally migrated to weechat+weechat slack plugin. For a moment I thought I was too late, as slack is killing the xmpp and irc bridges - but the dedicated slack plugin for weechat uses the slack api. As an added bonus, there are no more animated emojis in my peripheral vision that can be mistaken for an update / alert. I'm on Linux, but I presume wc works fine on Mac. A bit of a shame that the qt-based client seems abandoned - but it's open source and python so maybe it'll pick up some steam for those that want something a bit less console only, but still not Web app crappy. https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack https://github.com/weechat/weechat https://github.com/weechat/weechat https://github.com/weechat/qweechat https://github.com/weechat/qweechat I imagine that both for the console client and the qt one it should be possible to map some of the more common emojis to Unicode (eg :heart:).
- taneq 9y ago
  I don't have a horse in the slack/xmpp race (although I do hope open standards win out) but if they have a public API which lets you do all that, would it be easy enough to build an XMPP gateway?
  - auscompgeek 9y ago
    IRCCloud have actually written a IRCv3 gateway for Slack (although it's not open... yet): https://twitter.com/IRCCloud/status/971416931373854721 https://twitter.com/IRCCloud/status/971416931373854721
KnightEternal 9y ago
The joys of Electron...
sunnycodes 9y ago
One word: Javascript.
matt_oriordan 9y ago
This reminds me of the CPU issues there were previously with Slack: https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memory-gone-the-answer-slack-9e5c39207cab https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memor... Sounds like Slack doesn't have any type of performance testing as part of their release cycles.
emile14 9y ago
I'm a heavy user of Slack, but Slack 3.0.0 running on my MacOS 10.13.3 laptop is using less than 100MB memory. FWIW
emile14 9y ago
I'm a heavy Slack user (dozens of channels, open for weeks at a time), but Slack 3.0.0 running on my MacOS 1.13.3 laptop is only using ~75MB memory. FWIW
nextweek2 9y ago
I hate these questions. You need to put it in context. Is system ram under pressure? Poor memory performance is measured by swap i/o or bandwidth, not usage. If you have 16gb of ram and little else using the ram then there is nothing to worry about. If you have 4gb of ram then a support ticket is probably your best course of action rather than whining to random forums. To answer your question, runtimes will lazy garbage collect because you might want the data again. Decompressed images and frame buffers lead to faster under interface interaction. You're not using a terminal app, you're using an app that can render any font or image in complex ways to an image buffer, for rendering at 60fps with smooth scroll. Are you also on a retina display?

53 points by ktamiola 9y ago

Can somebody explain to me why the Slack app drains >3.5GBs of memory. I am using the version 3.1.0 on 10.10.5 OSX. Am I the only "lucky" user getting such a poor memory performance?

reustle 9y ago

I get around this by using the web client daily (pinned tab in chrome) and open up the desktop app whenever I need to do specifically screen sharing (or just skype). It's not worth the resource headache.

enraged_camel 9y ago
Same. The web client has feature parity with the desktop client so I haven’t understood why people bother with the latter.
- phereford 9y ago
  It does not have complete feature parity. One of the things missing, that is important for me and the team I am on, is the ability to share screens and allow for remote control in that session. That is a Mac App only right now, at least the last time I checked.
  - lojack 9y ago
    Now that screenhero is no more, screen sharing is literally the only reason one of my teams use slack. We use hipchat (not by choice) for the rest of our communication.
- Cthulhu_ 9y ago
  For me, cmd + tabbing to a chat application is a much better user experience than having to dig through open tabs and/or multiple instances of the browser.
  - reustle 9y ago
    Since it's a pinned tab, it's always number X (3 in my case). CMD+3 inside chrome always takes me there.
lallysingh 9y ago
Also Ctrl-F let's you find people in the list of chats.

framel 9y ago

Electron is cancer

api 9y ago
We've been making the rounds over all the options over and over again for planning a new app, and we always reluctantly come back to Electron. Qt? No mobile, slower development. Java? No mobile, deployment nightmare, Oracle cooties, and often just as heavy as Electron. Native UI? Out of the question. We don't have anywhere near the resources to develop our app four to five times, implement every new feature four to five times, etc. Others are some combination of immaturity, lack of mobile support, out of date, lack of support for internationalization and accessibility, etc. I agree that Electron is cancer, but until there's a better game in town it's the only thing that could possibly meet our needs. We would pay for a better option, but unfortunately there are probably not enough of us to make another option economically viable. Nobody pays for developer tools so it's an awful market for startups, and a modern UI API with cross platform capability is just too much work for independent open source efforts. My dream would be a really clean cross platform UI library that lets you develop in a language like Go or Rust. UI development in 2018 is a sad state of affairs. It was better in many ways in the 1990s and early 2000s. We had wxWidgets and Qt then and they were decent. Mobile "ruined" it by introducing another incredibly popular UI paradigm that rendered literally everything written to date obsolete.
- framel 9y ago
  https://www.qt.io/mobile-app-development/ https://www.qt.io/mobile-app-development/
  - api 9y ago
    That's QML, which isn't that different from a browser rendering engine. I'm talking about an actual native UI implemented in native code, not a weird quasi-browser. Of course Qt itself also has quasi-browser features like its style sheet widget styling stuff. If we're going there, why not just use HTML5/JS which has a million billion times more support? Also C++ is not really the best option. I code systems software in C++ but for UI dev it's not quite productive enough. I've worked with large Qt code bases before and no thanks. I suppose if they've modernized it and incorporated C++11 features it might be more bearable, but in the past it was a pretty awful mess of raw pointers and ownership semantics bugs and very very long compile times.

matthewmacleod 9y ago

What I find interesting is that this is now becoming more noticed by other people. We've had a whole bunch of non-tech people at my company start complaining about Slack's sluggish performance, connection drops, the fact that it makes other things on their machine unusable, that kind of stuff. I would like to think this means there will be a bit of a change going forward.

dijit 9y ago

No, that's the default slack experience if you have a lot of teams. I recommend: * Disabling emoji support, especially animated emojis> * Disabling auto-expanding of images (gifs are egregious) * Use compact display * Limit number of channels/groups you're in if possible, surely you don't need all those channels. Doing this curbed my resource usage quite a lot. I don't miss emoji's all that much.

znpy 9y ago
I didn't even know all of those things were possible! Thank you!
cimmanom 9y ago
Hm, I wonder how much a company's Slack culture affects memory usage. I've never seen it eat more than a few hundred MB, but then my coworkers almost never post GIFs.

deleted 9y ago

[deleted]

totallysnowman 9y ago

This is what you get when you use a full-blown web browser for a simple messaging app.

deleted 9y ago
[deleted]

acd 9y ago

FreeBSD an entire operating system runs on about 100MB ram. https://www.freebsd.org/doc/handbook/bsdinstall-hardware.html https://www.freebsd.org/doc/handbook/bsdinstall-hardware.htm...

znpy 9y ago
CentOS 7 is roughly the same. For a minimal install (with ssh service and vsftpd), i booted it and flushed the filesystem cache, then ram usage was about 88MB.
- Koshkin 9y ago
  Heh, the recommended amount of RAM to run Windows 95 was 8MB.

kevingadd 9y ago

I once had it hit 40gb of memory usage. I bought more RAM.

yoz-y 9y ago

A lot of digital ink was spent on this issue. Basically it is due to the fact that the Slack app uses Electron, and thus it is not much more than a Chromium browser with several loaded webpages.

qaq 9y ago
VS Code is an electron app
- maushu 9y ago
  I think they use their own implementation and not electron.
- jrs95 9y ago
  And it sucks at this too. Just not as badly as Slack or Atom.

onion2k 9y ago

Am I the only "lucky" user getting such a poor memory performance? No, that's very common. For most people Slack's usefulness outweighs it's poor memory footprint.

d3ckard 9y ago

104 MB at the moment. For me at least, Slack really got their shit together sometime last year and improved the issue significantly. I still remember having to restart Slack twice a day, but it ain't issue anymore.

pointe 9y ago
Roughly 800MB for me at the moment. 95MB main process, 2 helpers at 50MB and 1 helper at 600MB.
nellyspageli 9y ago
Yeah, mine is 122MB at the moment as displayed in the OS X Activity monitor.
- deleted 9y ago
  [deleted]
- eddieroger 9y ago
  Continuing the anecdata collection, I'm in the over 1GB club. One instance of Slack, six of Slack Helper, several of which using 200GB of memory, but the biggest being 1GB. Timely thread, since when I sat down this morning and unlocked my computer, I was warned that I'd run out of memory and needed to quit some apps.
  - vog 9y ago
    > several of which using 200GB of memory I really, really hope you mean "200MB", although I honestly wouldn't be surprised if they managed to use 200GB if accidentally started on a beefy server.
lojack 9y ago
Would probably help to say how many slack organizations you’re using. I’m on around 6, and Slack almost always takes up a big chunk of memory. I suspect those with less resource usage are in fewer orgs, but it’s hard to say.
9y ago

steeve 9y ago

I don't use the app anymore and open it in my browser as a regular tab. Much much better.

stephenSinniah 9y ago
I have a MPB 2012 and I purchased a second hand ipad mini2 just so I could handle all my comms through it. Slack was the main culprit for that decision, my computer was basically unusable while running rails with guard + ember + chrome(pivotal tracker) + slack.

makkesk8 9y ago

to be fair, this is not an electron issue as vscode runs fine on all platforms. I don't really want to bash the devs but... Maybe they should take a look at it.

ktamiola 9y ago
That's what I have also thought about this!
w0utert 9y ago
I have vscode open with a relatively small project here, and excluding the CPP tools it sits at about ~500M used. If I include the CPP tools it's about ~1.5GB. Not as bad as Slack, but I wouldn't call it 'fine' considering that it's just an editor.
- seba_dos1 9y ago
  For comparison, QtCreator with I'm using right now in one session for a few days, with a full-blown set of C++ tools integrated, consumes 319.1 MB RAM + 140.3 MB RAM for clangbackend. That's less than 500 MB for a complete solution with code analysis, debugger, profilers, form designer and even some QML stuff. Slack, which is idling in the background in just one organization, consumes 22 MB more than QtCreator :P OTOH, there's also a full-blown IRC client Konversation, connected to 2 servers and 42 channels total, consuming 80.6 MB.
theknarf 9y ago
Vscode is the best optimized Electron app out there.
natecavanaugh 9y ago
VS Code is by far the best optimized Electron app I've seen, but with a total of 5 files open, it will still turn my laptop into a pizza oven on my lap. It, and every JS/Desktop hybrid has so much promise, but my Lord, as a proficient JavaScript junkie that has a deep abiding love for the language, it's not performant. I just can't use either Atom or VS Code for day to day work. PS, Sublime, please support some form of JS plugins, even if that means limiting the API for JS plugins.

unfunco 9y ago

If you're signed into many workspaces, try closing a few.

e12e 9y ago

I quickly abandoned the slack "App", but even dedicating a chromium tab to Slack ended up being absurdly heavy. So I've finally migrated to weechat+weechat slack plugin. For a moment I thought I was too late, as slack is killing the xmpp and irc bridges - but the dedicated slack plugin for weechat uses the slack api. As an added bonus, there are no more animated emojis in my peripheral vision that can be mistaken for an update / alert. I'm on Linux, but I presume wc works fine on Mac. A bit of a shame that the qt-based client seems abandoned - but it's open source and python so maybe it'll pick up some steam for those that want something a bit less console only, but still not Web app crappy. https://github.com/wee-slack/wee-slack https://github.com/wee-slack/wee-slack https://github.com/weechat/weechat https://github.com/weechat/weechat https://github.com/weechat/qweechat https://github.com/weechat/qweechat I imagine that both for the console client and the qt one it should be possible to map some of the more common emojis to Unicode (eg :heart:).

taneq 9y ago
I don't have a horse in the slack/xmpp race (although I do hope open standards win out) but if they have a public API which lets you do all that, would it be easy enough to build an XMPP gateway?
- auscompgeek 9y ago
  IRCCloud have actually written a IRCv3 gateway for Slack (although it's not open... yet): https://twitter.com/IRCCloud/status/971416931373854721 https://twitter.com/IRCCloud/status/971416931373854721

KnightEternal 9y ago

The joys of Electron...

sunnycodes 9y ago

One word: Javascript.

matt_oriordan 9y ago

This reminds me of the CPU issues there were previously with Slack: https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memory-gone-the-answer-slack-9e5c39207cab https://medium.com/@matt.at.ably/wheres-all-my-cpu-and-memor... Sounds like Slack doesn't have any type of performance testing as part of their release cycles.

emile14 9y ago

I'm a heavy user of Slack, but Slack 3.0.0 running on my MacOS 10.13.3 laptop is using less than 100MB memory. FWIW

emile14 9y ago

I'm a heavy Slack user (dozens of channels, open for weeks at a time), but Slack 3.0.0 running on my MacOS 1.13.3 laptop is only using ~75MB memory. FWIW

nextweek2 9y ago

I hate these questions. You need to put it in context. Is system ram under pressure? Poor memory performance is measured by swap i/o or bandwidth, not usage. If you have 16gb of ram and little else using the ram then there is nothing to worry about. If you have 4gb of ram then a support ticket is probably your best course of action rather than whining to random forums. To answer your question, runtimes will lazy garbage collect because you might want the data again. Decompressed images and frame buffers lead to faster under interface interaction. You're not using a terminal app, you're using an app that can render any font or image in complex ways to an image buffer, for rendering at 60fps with smooth scroll. Are you also on a retina display?