5 ms·

HIGH CPU usage on Mac

52 points by throwaway13337 10y ago

jwr 10y ago
I think too few people know about this sort of problem or care about it. Dropbox is another example of a well-known CPU hog: on a Mac, it still insists of watching and processing all filesystem changes, not just those inside the Dropbox subtree, so any file operation you perform anywhere on the computer has a Dropbox tax. You pay with your battery life. And yet, after so many years, this is not enough of an annoyance for them to work on it.
- JustSomeNobody 10y ago
  I don't let dropbox run in the background. I don't need it all the time, so i don't let it run all the time. I really wish they'd fix their junk. As a developer, I hate that we're becoming a bunch of "whatever"s. I mean this is junk behavior.
  - wkd 10y ago
    Completely agree, for example chrome has been observed flushing full state data to disk at regular intervals even with no changes since 2010[1] which is eating battery and SSD lifetime. Firefox does this too as far as I know. Not to mention the battery impact of poorly written javascript SPA's or advertisements. [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=52663 https://bugs.chromium.org/p/chromium/issues/detail?id=52663
    - yoklov 10y ago
      It's hard to know what the right call is here. In most cases the battery life hit seems to be fairly minimal (I've never noticed it in any browser, even back when I used chrome), and preventing data loss is, well, fairly important -- at least it can be depending on the site. OTOH there are almost certainly sites that trigger very bad behavior here. While I've never dug into it too much, it wouldn't surprise me that session store was part of why e.g. IRCCloud or Slack have such high power usage (although I don't know for certain -- it could just as easily be something else). My understanding is that SSD lifetimes concerns are largely misplaced (or at the very least, only relevant for a fairly small subset of users) and that even reasonably old SSDs can handle well into petabytes of writes -- which is far above what this behavior can reasonably approach. But power usage concerns are totally legitimate IMO. Full disclosure: I'm not unbiased here, I work on Firefox (but have never touched session store).
- nerdponx 10y ago
  Is there any reason to trust that Dropbox isn't phoning home with full knowledge of how you use your computer?
- gumby 10y ago
  This is especially absurd because Apple provides an API (fsevents) specifically designed to let you subscribe to the filesystem changes you care about. But the lump of python dropbox ships as their "application" doesn't know about it. And instead of putting two engineers on fixing this they also try to "add value" by hijacking the accessibility support of your computer. Fortunately Apple catches this, warns you, and lets you say no. Despite all this: I have tried Box, Onedrive, iCloud Drive, and Google Drive and still, Dropbox sucks the least in terms of naive user compatibility and fewest surprises. I don't know why this is so hard to get right!?
Jdam 10y ago
Welcome to the wonderful world of super-portable web-tech-based apps.
- antihero 10y ago
  Surely this could be an issue with any app though.
  - cguess 10y ago
    It must be. They're not pulling a Slack and running a full WebKit in their app. The internal library on MacOS is written in C (or was, they were moving to Objective-C last year).
gpderetta 10y ago
AKA "'sleep(2)' is not a synchronization primitive". Not that this issue is necessarily due to sleep itself, but likely due to active polling instead of event handling.
anlif 10y ago
I have had quite a few issues with Spotify on OSX, but not any issues like this lately. The forum post is old, and the most recent answer is from June last year. Is this really still relevant?
- gurkendoktor 10y ago
  I've had it happen in late 2016. Threads about this issue come and go: https://community.spotify.com/t5/forums/searchpage/tab/message?filter=dateRangeType&q=cpu&rangeTime=1M https://community.spotify.com/t5/forums/searchpage/tab/messa...
Luc 10y ago
The last comment on that thread is from June 2016. I think this has since been fixed?
- 1_player 10y ago
  Nope, got hit by that bug yesterday.
- Shish2k 10y ago
  I'm also still getting hit by it; every 2-3 days that app will suddenly max out a single core and not stop until I kill it :(
tornadoboy55 10y ago
For all people saying this has been fixed: my Spotify on macOS regularly will spike to 90% usage when idling and stay there until I kill it. Reinstalls change nothing.
gdulli 10y ago
They probably don't prioritize the desktop player but it's the thing that made me cancel my $10/month subscription. (Not this CPU issue, but general lack of parity with other players and no movement in that direction.)
- raverbashing 10y ago
  Well, there's the web player as well, but the desktop app seems better
JulianVModesto 10y ago
Seems like a good reason to go @jessfraz and containerize your Spotify client until there's a fix. https://github.com/jessfraz/dockerfiles/tree/master/spotify https://github.com/jessfraz/dockerfiles/tree/master/spotify
Normal_gaussian 10y ago
This isn't fixed, it just isn't as bad as it used to be. When they had apps spotify would spin at ~90% of one core for me. When they had just musixmatch, spotify would switch between 30% and 60%. Now it decides to randomly run at 90% for about ten seconds every few songs. A workaround: cat ~/bin/music #!/bin/bash error() { echo "[Error] $@" 1>&2 } if [ -z "$(which cpulimit 2>/dev/null)" ]; then error "Missing package cpulimit" exit 1 fi if [ -z "$(which spotify 2>/dev/null)" ]; then error "Missing package spotify" exit 2 fi if test -t 1; then exec 1>/dev/null fi if test -t 2; then exec 2>/dev/null fi launch() { cpulimit -l 30 spotify } launch & And I see no degradation in performance. This is severely low quality software engineering.
bfrog 10y ago
Yay for electron apps!
- PascLeRasc 10y ago
  I don't believe Spotify is an electron app on any platform.
  - worg 10y ago
    Although it isn't an electron app it's just a bunch of CEF (Chrome-ium- Embedded Framework) 'panels' mixed in a single window so it's pretty close to an electron app
lj3 10y ago
Did they ever fix the issue where the desktop app would kill SSDs by performing a large number of writes? I stopped using the desktop version back in October because of that issue.
- WalterSear 10y ago
  There were news articles announcing a bug fix.
technojunkie 10y ago
I'm hoping that the web version doesn't commit the sins of the desktop version. For those of us using Chrome, uninstall Spotify desktop app. Make sure you have uBlock and Privacy Badger installed, go to https://play.spotify.com https://play.spotify.com, sign in, and enjoy ad-free Spotify.
dispat0r 10y ago
I'm running spotify 1.0.47 on linux and there's no idle cpu usage from spotify. If I play a song it's using ~ 10% cpu.

jwr 10y ago

I think too few people know about this sort of problem or care about it. Dropbox is another example of a well-known CPU hog: on a Mac, it still insists of watching and processing all filesystem changes, not just those inside the Dropbox subtree, so any file operation you perform anywhere on the computer has a Dropbox tax. You pay with your battery life. And yet, after so many years, this is not enough of an annoyance for them to work on it.

JustSomeNobody 10y ago
I don't let dropbox run in the background. I don't need it all the time, so i don't let it run all the time. I really wish they'd fix their junk. As a developer, I hate that we're becoming a bunch of "whatever"s. I mean this is junk behavior.
- wkd 10y ago
  Completely agree, for example chrome has been observed flushing full state data to disk at regular intervals even with no changes since 2010[1] which is eating battery and SSD lifetime. Firefox does this too as far as I know. Not to mention the battery impact of poorly written javascript SPA's or advertisements. [1]: https://bugs.chromium.org/p/chromium/issues/detail?id=52663 https://bugs.chromium.org/p/chromium/issues/detail?id=52663
  - yoklov 10y ago
    It's hard to know what the right call is here. In most cases the battery life hit seems to be fairly minimal (I've never noticed it in any browser, even back when I used chrome), and preventing data loss is, well, fairly important -- at least it can be depending on the site. OTOH there are almost certainly sites that trigger very bad behavior here. While I've never dug into it too much, it wouldn't surprise me that session store was part of why e.g. IRCCloud or Slack have such high power usage (although I don't know for certain -- it could just as easily be something else). My understanding is that SSD lifetimes concerns are largely misplaced (or at the very least, only relevant for a fairly small subset of users) and that even reasonably old SSDs can handle well into petabytes of writes -- which is far above what this behavior can reasonably approach. But power usage concerns are totally legitimate IMO. Full disclosure: I'm not unbiased here, I work on Firefox (but have never touched session store).
nerdponx 10y ago
Is there any reason to trust that Dropbox isn't phoning home with full knowledge of how you use your computer?
gumby 10y ago
This is especially absurd because Apple provides an API (fsevents) specifically designed to let you subscribe to the filesystem changes you care about. But the lump of python dropbox ships as their "application" doesn't know about it. And instead of putting two engineers on fixing this they also try to "add value" by hijacking the accessibility support of your computer. Fortunately Apple catches this, warns you, and lets you say no. Despite all this: I have tried Box, Onedrive, iCloud Drive, and Google Drive and still, Dropbox sucks the least in terms of naive user compatibility and fewest surprises. I don't know why this is so hard to get right!?

Jdam 10y ago

Welcome to the wonderful world of super-portable web-tech-based apps.

antihero 10y ago
Surely this could be an issue with any app though.
- cguess 10y ago
  It must be. They're not pulling a Slack and running a full WebKit in their app. The internal library on MacOS is written in C (or was, they were moving to Objective-C last year).

gpderetta 10y ago

AKA "'sleep(2)' is not a synchronization primitive". Not that this issue is necessarily due to sleep itself, but likely due to active polling instead of event handling.

anlif 10y ago

I have had quite a few issues with Spotify on OSX, but not any issues like this lately. The forum post is old, and the most recent answer is from June last year. Is this really still relevant?

gurkendoktor 10y ago
I've had it happen in late 2016. Threads about this issue come and go: https://community.spotify.com/t5/forums/searchpage/tab/message?filter=dateRangeType&q=cpu&rangeTime=1M https://community.spotify.com/t5/forums/searchpage/tab/messa...

Luc 10y ago

The last comment on that thread is from June 2016. I think this has since been fixed?

1_player 10y ago
Nope, got hit by that bug yesterday.
Shish2k 10y ago
I'm also still getting hit by it; every 2-3 days that app will suddenly max out a single core and not stop until I kill it :(

tornadoboy55 10y ago

For all people saying this has been fixed: my Spotify on macOS regularly will spike to 90% usage when idling and stay there until I kill it. Reinstalls change nothing.

gdulli 10y ago

They probably don't prioritize the desktop player but it's the thing that made me cancel my $10/month subscription. (Not this CPU issue, but general lack of parity with other players and no movement in that direction.)

raverbashing 10y ago
Well, there's the web player as well, but the desktop app seems better

JulianVModesto 10y ago

Seems like a good reason to go @jessfraz and containerize your Spotify client until there's a fix. https://github.com/jessfraz/dockerfiles/tree/master/spotify https://github.com/jessfraz/dockerfiles/tree/master/spotify

Normal_gaussian 10y ago

This isn't fixed, it just isn't as bad as it used to be. When they had apps spotify would spin at ~90% of one core for me. When they had just musixmatch, spotify would switch between 30% and 60%. Now it decides to randomly run at 90% for about ten seconds every few songs. A workaround: cat ~/bin/music #!/bin/bash error() { echo "[Error] $@" 1>&2 } if [ -z "$(which cpulimit 2>/dev/null)" ]; then error "Missing package cpulimit" exit 1 fi if [ -z "$(which spotify 2>/dev/null)" ]; then error "Missing package spotify" exit 2 fi if test -t 1; then exec 1>/dev/null fi if test -t 2; then exec 2>/dev/null fi launch() { cpulimit -l 30 spotify } launch & And I see no degradation in performance. This is severely low quality software engineering.

bfrog 10y ago

Yay for electron apps!

PascLeRasc 10y ago
I don't believe Spotify is an electron app on any platform.
- worg 10y ago
  Although it isn't an electron app it's just a bunch of CEF (Chrome-ium- Embedded Framework) 'panels' mixed in a single window so it's pretty close to an electron app

lj3 10y ago

Did they ever fix the issue where the desktop app would kill SSDs by performing a large number of writes? I stopped using the desktop version back in October because of that issue.

WalterSear 10y ago
There were news articles announcing a bug fix.

technojunkie 10y ago

I'm hoping that the web version doesn't commit the sins of the desktop version. For those of us using Chrome, uninstall Spotify desktop app. Make sure you have uBlock and Privacy Badger installed, go to https://play.spotify.com https://play.spotify.com, sign in, and enjoy ad-free Spotify.

dispat0r 10y ago

I'm running spotify 1.0.47 on linux and there's no idle cpu usage from spotify. If I play a song it's using ~ 10% cpu.