Dropbox is <i>terrible</i> with CPU usage. This is something I reported to them several times, but it seems they don't really care.<p>Last I tested, Dropbox consumed CPU for ANY changes ANYWHERE in your filesystem, not just within the Dropbox folder. So its (slow) code processed changes even when you untarred a large set of files somewhere in /tmp.<p>I also stopped using Dropbox for storing my code because of that — it's nearly useless, as it consumes so much CPU and eats so much battery life, that it simply isn't worth the effort.<p>Another problem with Dropbox is that upon login it indexes the entire Dropbox, which if you have an HDD basically kills the machine for several minutes, e.g. you can't do anything else. That happens to me on a Mac Pro. On an SSD-equipped MacBook things are better, but it's still a monstrous operation.<p>And to everyone that says you should not store code in dropbox: a) there are good and legitimate reasons for doing so, b) dropbox could work a little more on optimizing CPU usage instead of adding "save your photos to Dropbox" features.
That finding might be quite interesting and all... but I'm thoroughly confused about that guy always quoting power consumption in mAh (which is the unit for electrica charge).<p>I'd also check if that guy's dropbox daemon(s) are stuck in an obvious loop. I'm logged on in my private server, and when it's idle there's hardly any activity on the dropbox threads, the main CPU consumer is one servicing what I suspect to be the main select() loop. And that thread basically stat()ing the .dropbox/config.dbx file every 2 seconds, and reads 16 bytes out of it. That should hardly be measureable in terms of power consumptions on a modern CPU.
> I use it to store my code repository [...] Not using Dropbox is not an option for me as I switch machines several times during the day.<p>I'd suggest you invest in a hosted git repo.
I had this happen in the past too and found it to be the result of two issues:<p>1) Using dropbox to house a very large git repo with massive changes and tons of branches... Every time I switched branches, the hundreds of files would change and obviously kick off a major sync job.<p>2) There were a few files in a folder than had the owner set to the wrong owner and Dropbox couldn't get permission to access them. This caused it to get stuck in a loop trying to sync those files and Dropbox ended up running my CPU up to over 100% load.<p>Fix those issues and you shouldn't see it causing any more problems with your battery life.
The only takeaway is that his power usage shouldn't be that high with Dropbox idling/paused. But given that he's
* surprised at it using a lot of power when doing the initial sync
* decided to have a git repo inside Dropbox (just don't do it, you will run into trouble; and it will cause heavy sync activity, thus waking CPU and wifi)
* using a unit of capacity to express power consumption<p>I'm not sure I trust his methods.<p>I regularly turn off Dropbox on and off when switching between mobile broadband and wifi, and haven't seen any difference in power consumption. That's on Ubuntu 13.04 @ Thinkpad T530.
One solution to the whole "storing source in dropbox" problem that I liked to use previously (using bitbucket now instead) is just to have a bare git repo in dropbox + the real checkout somewhere else and just push commits to the bare dropbox repo whenever I'm about to switch machine. Could even be set up to happen more automagically since the repo isn't shared.<p>Syncing binaries (I mainly work in C#) and lots of small changes seems silly to me.
I switched from Dropbox to SpiderOak recently, and they're a bit better, but feels so clunky. I'm just about fed up with all of them. I use CrashPlan for backups and they're at least good for CPU usage because they have a preference -- max CPU (%) when you're at the computer, and max CPU when you're away, which really does help.<p>Those who are using Dropbox may find something like cpulimit[1] useful. This limits the CPU usage of any process by repeatedly sending SIGSTOP and SIGCONT signals to your process. It's on homebrew for OS X. I think there're some other alternatives available too but can't remember off hand. But if the article's accurate, Dropbox has issues even when it's not indexing heavily.<p>[1] <a href="https://github.com/opsengine/cpulimit" rel="nofollow">https://github.com/opsengine/cpulimit</a>
<i>"I just have to change my habit of having it constantly on while working. Turn Dropbox on and sync before starting to work and then turn it off."</i><p>Hohoho. Allow me to suggest a solution. Suppose that you would be ok with having Dropbox sync files every five minutes. Let's suppose that 10 seconds is usually more than enough to do whatever syncing is necessary. Well, then:<p><pre><code> $ while :; do killall -STOP Dropbox; sleep 300; killall -CONT Dropbox; sleep 10; done
</code></pre>
I do things like this to throttle the CPU usage and, in some cases, the power consumption of applications that really don't need what they're using. This really should be a feature provided by the operating system, but in the meantime, I resort to ridiculous hacks of this sort. (Note that, if you ^C the above loop, Dropbox will likely be still STOPped and you'll have to CONT it again. It is possible to write a more sophisticated program to address this problem.)
This happens to me as well.<p>The Dropbox daemon wakes up every 10-15 seconds, uses 15% of the CPU then goes back to sleep. All this without any files changed or the index being affected. On 10.8, 10.9 with official versions and betas. Noticeable because I am on an older C2D MacBook Pro.<p>Wondering whether it's a side effect of something else installed e.g. iStat Menus.
This is interesting, I've also got a 2013 MBA and use DropBox but I've not seen a big dip in battery usage. I might do a bit more testing this week and see whether it has had an impact and I've just not realised, and/or I've put it down to the code-compile-simulator cycle.
I see this problem happening only to me when it's used as code repository. Which is what he is doing. I had that for one project because the client didn't want to use git, but it's horrible. So, logically, when you have a lot of files changing all the time (compiling (xcode, eclipse), adding libraries (node, RoR)) you'll see dropbox taking over your computer. For all other uses it seems fine.<p>Note also that when you have the issue with a lot of small files, during/after dropbox is done, Finder / mds will jump to the top of your top indexing the files. I disabled mds in my projects directory and will never place active source directories in dropbox again.
Can anyone confirm his findings? I imagine that if this is real, then this is a problem for all MacBook owners not just the latest MacBook Air.<p>I have a 13" MacBook Air, medio 2011. I bought it almost right after it was released and have used it as my only computer almost every day since. I have the Dropbox agent running all the time.<p>While working last Sunday I got 5.5 hours of battery life out of it and I've never taken good care of the battery. I never drain it unless I'm not near a power outlet, in which case I just have it plugged in all day.<p>My current battery health information shows:
Cycle Count: 253,
Condition: Normal
I have a cron script running on my MacBook to make sure the Dropbox client priority is always set to 20 (lowest). I also pause the client manually when moving to battery power. I really wish there was a better solution, like switching to a similar service that offers decent (or at least acceptable) software, but almost everyone else uses the same setup with terrible 'universal' Java/Python/etc-based clients that absolutely suck at synchronizing large amounts of data.
Laptop operating systems need to start keeping tabs on what's using your battery, like Android does (with mixed success but that's another story).
Open Dropbox when you need to sync, then quit the process. Make sure it doesn't run at OS X start up. I don't see why most of the users want to have a perfect sync all day long since it doesn't happen in real time (large files, slow network, etc.)
Oh if only it was one App that killed the battery on the last laptop I bought. Before nuking the default windows install, I did a quick test, with all the crapware that comes as standard, it managed about 4 hours. Fresh install 6.5 hours.
Since I'm stuck using an old computer I made a small script that turns Dropbox on every few hours and kills it after 10 minutes. I don't sync data all the time so this solution works well for me and I save system resources.
I push to a bare repo in a dropbox folder because I can't for the life of me get a secure connection through the work firewalls / proxy so I don't bother and let dropbox deal with it.