6 ms·

A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-vie

by Ambroos 10y ago

A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Just did a quick check on my quadcore MBP, having Slack fullscreen out-of-view with nothing animated in view gives it a CPU usage of 0,1% with spikes up to 2,5%. Switch to a conversation with a single animated party parrot emoji, go to another fullscreen app once again, and CPU usage never drops below a whopping 22%. For an animated parrot cartoon. I'm not sure if this is a bug in Slack or Electron. Doing the same in Chrome does not cause any issues, as GIFs seem to be suspended when the window is not in view. CPU usage goes down to almost 0 when you switch away from your GIF-filled Chrome window. For Slack, however, it barely changes. A big shame. (On that note, I wonder how much power is wasted by party parrots via CPU usage. Where I work at least one is almost permanently visible in any conversation as a reaction emoji, so it's probably not insignificant.)

and0 10y ago
I want to say that VS Code had the same issue because of the blinking cursor, which was controlled by a CSS property to toggle.
- josephg 10y ago
  I'm consistently blown away that stuff like this gets past testing. Personally I think every software engineer should have a CPU meter of some for running on their machine while developing. Its an essential element of seeing what you're doing. How can you write decent software without having even that much visibility over what your computer is up to while your code runs? These huge CPU sinks making it through to release required nobody to even glance at a CPU graph.
  - artursapek 10y ago
    I can't live without one. I used to use "MenuMeters" on Mac, and now use "System Load Indicator" on Ubuntu: http://i.imgur.com/XHlNius.png http://i.imgur.com/XHlNius.png. I also visualize the system load in my tmux bar: http://i.imgur.com/y5KENxA.png http://i.imgur.com/y5KENxA.png I find them both extremely useful in finding when I'm running wasteful software (either written by myself or someone else). https://github.com/artursapek/dotfiles/blob/master/battery.rb https://github.com/artursapek/dotfiles/blob/master/battery.r... https://github.com/artursapek/dotfiles/blob/master/.tmux.conf#L64 https://github.com/artursapek/dotfiles/blob/master/.tmux.con...
  - Psilidae 10y ago
    I think this thinking is exactly how it gets past testing. You could force every engineer to have a CPU meter, but that alone won't help; they'll ignore it, assume it was a coworker's change that made the usage higher, or just assume their CPU is high because of their 30 Chrome tabs currently open while developing. A better solution would be to have CI monitor CPU usage so that increases/decreases could be monitored and reported over time/per commit.
    - yoodenvranx 10y ago
      You could force every engineer to have a CPU meter, No, you should force every developer to have a shitty Core 2 Duo CPU from 10 years ago. A lot of devs are working on new shiny i7s and that will hide a lot of performance problems because it's a top end CPU. Do your testing on a cheap box and if it is still smooth then you can ship your product.
    - deleted 10y ago
      [deleted]
  - fenomas 10y ago
    > These huge CPU sinks making it through to release required nobody to even glance at a CPU graph. Every bug looks egregious in hindsight; just because an app has one is no reason to assume the engineers who made it don't bother to test anything. Also: that particular issue only hurt idle CPU usage, and the usage was something like 13% CPU usage IIRC. It wasn't exactly the kind of thing that sets off klaxons.
    - josephg 10y ago
      > Every bug looks egregious in hindsight Most bugs are of the form "do X then Y then it doesn't work". These idle CPU bugs are reproduced simply by opening the application. I accept that 13% idle usage is invisible for most developers - but that's a bit disappointing. I notice stuff like this just by idly glancing at my CPU meter from time to time. An app that's sitting on high idle usage sets off klaxons for me.
      - fenomas 10y ago
        You're missing my point. All software has bugs; something always "makes it past test". Pointing at whichever bug did make it into production and saying "gosh those developers must not be testing anything" is silly.
- drewmate 10y ago
  I assume that's been patched; I just tested it and VS Code sat at about .01-.03% of CPU with a blinking block cursor (VSCode vim extension. Maybe it's better than the default I?). I noticed a few moments after startup that the CPU usage jumped to the 5-7% range for a couple seconds, then it notified me that an update was ready (I assume it was downloading/checking/processing that update). I don't know if this is Electron, or just a general trend in desktop apps, but it seems to be getting a lot easier to update them. So when those pesky CPU/memory hog bugs are found, they can be quickly patched. As for the general trade off that comes with running an extra Chromium process, I suppose it's up to users/developers as to whether it is worth it in each case.
- SippinLean 10y ago
  The underlying issue was with Chromium: https://github.com/Microsoft/vscode/issues/22900#issuecomment-288529120 https://github.com/Microsoft/vscode/issues/22900#issuecommen...
dagi3d 10y ago
have you reported such behaviour to Slack devs?
qeternity 10y ago
Slack and Spotify (Atom usually behaves alright) use a ton of CPU for me, and I almost never have GIFs in my Slack.
alkonaut 10y ago
How can animating a few gifs (or a few hundred) even use a noticable fraction of CPU? It's small images blitted from memory to screen. I agree with the author. Get off my lawn.
Mithaldu 10y ago
Note that you need to multiply your percentages by cpu core number.
- kevinchen 10y ago
  not on macOS, Linux, BSD etc. That only applies to Windows.
wfleming 10y ago
I've noticed the same myself, and I'm a bit surprised Slack hasn't done the same trick some of the larger image hosts have and started converting gifs to videos. Those hosts did it to cut bandwidth costs, but it also helps users as a side effect. (I continue to be amused that everyone records & shares gifs for "compatability" and "simplicity", but many of the places they're shared re-convert them into videos.)
- kevinchen 10y ago
  I know nothing about how Electron renders GIFs, but can guarantee you that there's no world where 16x16 animation should take up 20% CPU. Suggesting that we should convert them to tiny videos is completely missing the point.
  - wfleming 10y ago
    The problem is that in popular usage many GIFs are not 16x16. People are sharing high resolution GIFs that can weigh tens of MB, and rendering several of those at once (whether directly in Chrome or in Electron) is not a negligible amount of CPU. It shouldn't peg a core, of course, but it's definitely higher impact than videos of similar sizes, since video rendering is considerably more optimized for these cases than GIFs are.
notalaser 10y ago
> A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Holy fuck, can you imagine the supercomputers that were required to display Geocities websites in the 1990s?
- turrini 10y ago
  That was just gold
- magicalist 10y ago
  48x48 gifs with four frames of animation?
  - notalaser 10y ago
    The GIFs were significantly more complex than the single emoji that the parent comment mentioned. Actually, I think even a four-frame 48x48 gif is more complex than that "single animated parrot emoji" :-).
- Asooka 10y ago
  Well, back then we didn't have a composited desktop, so when the browser was out of view, no drawing was taking place. I kind of wish we would still have the option of programs just drawing directly to the screen rather than caching everything in private back buffers, but still use modern graphics techniques. I have a hunch that would actually be faster, since cpus have severely outpaced memory.
josephg 10y ago
Post author here. I thought about that, but there weren't any visible animations playing when I took those measurements. And the 5% figure survived a restart of the client. Its possible there were gifs playing above-the-fold somewhere and reloading themselves, but if so I'd say thats a bug somewhere in the interaction between the 15-20M lines of code in slack, electron and chrome. Its also worth noting that blog post is from a few months ago. Its possible the slack team has fixed the issue now. I wouldn't know because I deleted the slack desktop app and haven't looked back.
- mbell 10y ago
  Comparing CPU usage % across machines (or even runs on the same machine) without know the p-state doesn't make for a good comparison. This is especially true if you're on a fairly new processor with wide frequency operation range, 5% @ 1.3Ghz != 5% @ 3.5Ghz
  - Dylan16807 10y ago
    They are different, but both are much too high for what it's actually doing.
- webXL 10y ago
  Have you noticed any improvement in your other apps? I have Atom and Mattermost (Slack clone) running right now with very little avg. "energy impact". MM is at about a half gig in memory though.
andoma 10y ago
They can't really blame Chrome/Electron. If you ship it you own it.
- pdimitar 10y ago
  But they have responsibility as to what underlying tech they use. A responsibility they happily offload to someone else and go on their merry way -- and that's one of the big issues here.
gkya 10y ago
I didn't use that app ever but I guess w/ or w/o a gif, it won't use much CPU when it's idle. When scrolling a page-like thing that's already rendered, also then it probably doesn't do much computations. What, at all times, will be overtly consumed is going to be memory space. That may cause battery drainage and general slowness in the OS due to swapping, and even quicker wear-out of storage hardware. AFAIK Chrome takes hundreds of MBs of memory just right after startup, with nothing open.
deleted 10y ago
[deleted]
15155 10y ago
Free consulting for Slack: convert gifs to webm, intercept requests to download or save with the original gif. You're paying for the codecs, might as well use them.

by Ambroos 10y ago

and0 10y ago

I want to say that VS Code had the same issue because of the blinking cursor, which was controlled by a CSS property to toggle.

josephg 10y ago
I'm consistently blown away that stuff like this gets past testing. Personally I think every software engineer should have a CPU meter of some for running on their machine while developing. Its an essential element of seeing what you're doing. How can you write decent software without having even that much visibility over what your computer is up to while your code runs? These huge CPU sinks making it through to release required nobody to even glance at a CPU graph.
- artursapek 10y ago
  I can't live without one. I used to use "MenuMeters" on Mac, and now use "System Load Indicator" on Ubuntu: http://i.imgur.com/XHlNius.png http://i.imgur.com/XHlNius.png. I also visualize the system load in my tmux bar: http://i.imgur.com/y5KENxA.png http://i.imgur.com/y5KENxA.png I find them both extremely useful in finding when I'm running wasteful software (either written by myself or someone else). https://github.com/artursapek/dotfiles/blob/master/battery.rb https://github.com/artursapek/dotfiles/blob/master/battery.r... https://github.com/artursapek/dotfiles/blob/master/.tmux.conf#L64 https://github.com/artursapek/dotfiles/blob/master/.tmux.con...
- Psilidae 10y ago
  I think this thinking is exactly how it gets past testing. You could force every engineer to have a CPU meter, but that alone won't help; they'll ignore it, assume it was a coworker's change that made the usage higher, or just assume their CPU is high because of their 30 Chrome tabs currently open while developing. A better solution would be to have CI monitor CPU usage so that increases/decreases could be monitored and reported over time/per commit.
  - yoodenvranx 10y ago
    You could force every engineer to have a CPU meter, No, you should force every developer to have a shitty Core 2 Duo CPU from 10 years ago. A lot of devs are working on new shiny i7s and that will hide a lot of performance problems because it's a top end CPU. Do your testing on a cheap box and if it is still smooth then you can ship your product.
  - deleted 10y ago
    [deleted]
- fenomas 10y ago
  > These huge CPU sinks making it through to release required nobody to even glance at a CPU graph. Every bug looks egregious in hindsight; just because an app has one is no reason to assume the engineers who made it don't bother to test anything. Also: that particular issue only hurt idle CPU usage, and the usage was something like 13% CPU usage IIRC. It wasn't exactly the kind of thing that sets off klaxons.
  - josephg 10y ago
    > Every bug looks egregious in hindsight Most bugs are of the form "do X then Y then it doesn't work". These idle CPU bugs are reproduced simply by opening the application. I accept that 13% idle usage is invisible for most developers - but that's a bit disappointing. I notice stuff like this just by idly glancing at my CPU meter from time to time. An app that's sitting on high idle usage sets off klaxons for me.
    - fenomas 10y ago
      You're missing my point. All software has bugs; something always "makes it past test". Pointing at whichever bug did make it into production and saying "gosh those developers must not be testing anything" is silly.
drewmate 10y ago
I assume that's been patched; I just tested it and VS Code sat at about .01-.03% of CPU with a blinking block cursor (VSCode vim extension. Maybe it's better than the default I?). I noticed a few moments after startup that the CPU usage jumped to the 5-7% range for a couple seconds, then it notified me that an update was ready (I assume it was downloading/checking/processing that update). I don't know if this is Electron, or just a general trend in desktop apps, but it seems to be getting a lot easier to update them. So when those pesky CPU/memory hog bugs are found, they can be quickly patched. As for the general trade off that comes with running an extra Chromium process, I suppose it's up to users/developers as to whether it is worth it in each case.
SippinLean 10y ago
The underlying issue was with Chromium: https://github.com/Microsoft/vscode/issues/22900#issuecomment-288529120 https://github.com/Microsoft/vscode/issues/22900#issuecommen...

dagi3d 10y ago

have you reported such behaviour to Slack devs?

qeternity 10y ago

Slack and Spotify (Atom usually behaves alright) use a ton of CPU for me, and I almost never have GIFs in my Slack.

alkonaut 10y ago

How can animating a few gifs (or a few hundred) even use a noticable fraction of CPU? It's small images blitted from memory to screen. I agree with the author. Get off my lawn.

Mithaldu 10y ago

Note that you need to multiply your percentages by cpu core number.

kevinchen 10y ago
not on macOS, Linux, BSD etc. That only applies to Windows.

wfleming 10y ago

I've noticed the same myself, and I'm a bit surprised Slack hasn't done the same trick some of the larger image hosts have and started converting gifs to videos. Those hosts did it to cut bandwidth costs, but it also helps users as a side effect. (I continue to be amused that everyone records & shares gifs for "compatability" and "simplicity", but many of the places they're shared re-convert them into videos.)

kevinchen 10y ago
I know nothing about how Electron renders GIFs, but can guarantee you that there's no world where 16x16 animation should take up 20% CPU. Suggesting that we should convert them to tiny videos is completely missing the point.
- wfleming 10y ago
  The problem is that in popular usage many GIFs are not 16x16. People are sharing high resolution GIFs that can weigh tens of MB, and rendering several of those at once (whether directly in Chrome or in Electron) is not a negligible amount of CPU. It shouldn't peg a core, of course, but it's definitely higher impact than videos of similar sizes, since video rendering is considerably more optimized for these cases than GIFs are.

notalaser 10y ago

> A lot of Slack's high (background) CPU usage is caused by GIFs, in my experience. Holy fuck, can you imagine the supercomputers that were required to display Geocities websites in the 1990s?

turrini 10y ago
That was just gold
magicalist 10y ago
48x48 gifs with four frames of animation?
- notalaser 10y ago
  The GIFs were significantly more complex than the single emoji that the parent comment mentioned. Actually, I think even a four-frame 48x48 gif is more complex than that "single animated parrot emoji" :-).
Asooka 10y ago
Well, back then we didn't have a composited desktop, so when the browser was out of view, no drawing was taking place. I kind of wish we would still have the option of programs just drawing directly to the screen rather than caching everything in private back buffers, but still use modern graphics techniques. I have a hunch that would actually be faster, since cpus have severely outpaced memory.

josephg 10y ago

Post author here. I thought about that, but there weren't any visible animations playing when I took those measurements. And the 5% figure survived a restart of the client. Its possible there were gifs playing above-the-fold somewhere and reloading themselves, but if so I'd say thats a bug somewhere in the interaction between the 15-20M lines of code in slack, electron and chrome. Its also worth noting that blog post is from a few months ago. Its possible the slack team has fixed the issue now. I wouldn't know because I deleted the slack desktop app and haven't looked back.

mbell 10y ago
Comparing CPU usage % across machines (or even runs on the same machine) without know the p-state doesn't make for a good comparison. This is especially true if you're on a fairly new processor with wide frequency operation range, 5% @ 1.3Ghz != 5% @ 3.5Ghz
- Dylan16807 10y ago
  They are different, but both are much too high for what it's actually doing.
webXL 10y ago
Have you noticed any improvement in your other apps? I have Atom and Mattermost (Slack clone) running right now with very little avg. "energy impact". MM is at about a half gig in memory though.

andoma 10y ago

They can't really blame Chrome/Electron. If you ship it you own it.

pdimitar 10y ago
But they have responsibility as to what underlying tech they use. A responsibility they happily offload to someone else and go on their merry way -- and that's one of the big issues here.

gkya 10y ago

I didn't use that app ever but I guess w/ or w/o a gif, it won't use much CPU when it's idle. When scrolling a page-like thing that's already rendered, also then it probably doesn't do much computations. What, at all times, will be overtly consumed is going to be memory space. That may cause battery drainage and general slowness in the OS due to swapping, and even quicker wear-out of storage hardware. AFAIK Chrome takes hundreds of MBs of memory just right after startup, with nothing open.

deleted 10y ago

[deleted]

15155 10y ago

Free consulting for Slack: convert gifs to webm, intercept requests to download or save with the original gif. You're paying for the codecs, might as well use them.