49

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
    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 '17 at 19:57
28

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!

  • 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 '16 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 '16 at 17:08
  • 1
    That's neat, though. I should try to do that more often. Thanks – Steven Lu Apr 13 '16 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? – user2707001 Sep 19 '16 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. – Lassi Kinnunen Jun 1 '18 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.

  • 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 '16 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 '16 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). – Foliovision Mar 16 '16 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. – Lassi Kinnunen Jun 1 '18 at 9:49
8

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

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

You must log in to answer this question.

protected by Community Oct 24 '16 at 5:53

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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