55

I have noticed this often with large downloads such as Xcode updates and OS X updates and that sort of thing.

Basically we see this for however much time it takes for the download to proceed:

enter image description here

Today (currently) I am downloading Xcode 7.2.1.

You can see storedownloadd appears to be pegging an entire core, and about 30% of this work is handled by the kernel.

What I'm puzzled about is what is this "work"? Why does it need to do this work? What amount of processing could it possibly be doing, because decrypting a stream at a few megabytes per second does not require this much resources. I could be downloading a large file like this using hundreds of connections over the internet and running integrity checks on it (with a protocol like bittorrent) and it wouldn't approach anywhere close to what's happening here with resource use.

1
  • 1
    For anyone who doesn't need updates to download automatically and just wants to make this CPU usage go away, go to Apple Menu -> System Preferences -> App Store and uncheck the option "Download newly available updates in the background" (El Capitan) and then restart the computer.
    – rakslice
    Jan 9, 2017 at 19:57

3 Answers 3

33

Ran into the same issue today when updating XCode: storedownloadd pegs a CPU core for 20 minutes.

I tried breaking into storedownloadd with a debugger and saw some really long stack traces and a lot of time spent inside Security::CodeSigning.

I suspect that it is recursively verifying the digital signatures of a lot of tiny files one-by-one. I have no idea why it would do that instead of verifying the whole package as it is being downloaded. I also see a lot of string manipulation inside Security_CodeSigning::RequirementLexer::RequirementLexer.

Whatever storedownloadd does, it is too damn slow!

6
  • How were you able to see stack trace content? (Doesn't that generally require debug symbols?) Did you use Xcode to debug storedownloadd? Instruments? How do you do that?
    – Steven Lu
    Apr 13, 2016 at 17:05
  • @StevenLu Yeah, I used Xcode. I don't think I have debug symbols. The function names probably came from the shared libraries which declare those functions.
    – Navin
    Apr 13, 2016 at 17:08
  • 1
    That's neat, though. I should try to do that more often. Thanks
    – Steven Lu
    Apr 13, 2016 at 21:02
  • 2
    it's doing that BEFORE the download begins... so if it checks code signing, it does that at local files. maybe it's checking the integrity of the whole local xcode installation before download? Sep 19, 2016 at 15:51
  • 1
    it's doing it for me now when there are updates to be downloaded, but it is not downloading them yet. makes everything borderline unusable. just killed it in activity monitor and got my builds for the day done quicker. Jun 1, 2018 at 9:46
11

The CPU usage is caused by both sloppy coding and encryption/decompressing. Engineers have become very careless with our CPU in the age of quad core notebooks with eight virtual cores.

Someone should chase Apple around about optimising the storedownloadd routine. Considering that we had to put up with broken networking for over a year until Apple replaced the broken by design discoveryd with mDNSresponder.

Darker thoughts might suggest that the store is also compressing data for upload and sending it. Microsoft was caught out doing this many times but I haven't seen a documented case in Apple's case.

4
  • 1
    I think one thing we should consider is that maybe storedownloadd is uncompressing package data in a really computationally intensive way. There's not much reason at this point to suspect anything particularly nefarious
    – Steven Lu
    Mar 15, 2016 at 23:36
  • Sorry you actually did mention it. so I do mean to say that I think the most plausible thing is that this has something to do with file decompression.
    – Steven Lu
    Mar 15, 2016 at 23:48
  • 1
    Steven, even decompression doesn't make sense over the period of a long download (decompression usually happens at the end of a download). Only encryption makes sense. I think it's a situation like discoveryd where the code has never been properly optimised (the Ars Technica citation clearly shows just how behind Apple is in fixing core OS X routines, even one's far more central to user experience than store downloading - which shouldn't be that big a part of any non-tester user's total Mac experience). Mar 16, 2016 at 0:05
  • It makes no sense that they gave it priority over normal user tasks though. It running makes xcode do it's build much slower on the slower macs. 5 minutes turning to 20 minutes slow, not just a little bit slower. Jun 1, 2018 at 9:49
8

just killed it in terminal ;-) ...taking 1.5MB/s from my slow broadband

killall storedownloadd
1
  • 2
    So you won't get the software updates... doesn't sound like a solution to me.
    – Calimo
    Apr 12, 2019 at 8:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .