27 comments

[ 4.6 ms ] story [ 67.1 ms ] thread
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.
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.

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

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).

Is there any reason to trust that Dropbox isn't phoning home with full knowledge of how you use your computer?
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!?

Welcome to the wonderful world of super-portable web-tech-based apps.
Surely this could be an issue with any app though.
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).
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.

The last comment on that thread is from June 2016. I think this has since been fixed?
Nope, got hit by that bug yesterday.
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 :(
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.
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.)

Well, there's the web player as well, but the desktop app seems better
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.
Yay for electron apps!
I don't believe Spotify is an electron app on any platform.
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
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.
There were news articles announcing a bug fix.
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, sign in, and enjoy ad-free Spotify.

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.