Re: GCD killed my performance
Re: GCD killed my performance
- Subject: Re: GCD killed my performance
- From: Quincey Morris <email@hidden>
- Date: Thu, 24 Apr 2014 22:30:42 -0700
On Apr 24, 2014, at 20:14 , Jens Alfke <email@hidden> wrote:
> On my MacBook Pro this gave me a nice speedup of 50% or more.
>
> But when I tested the code on my iPhone 5 today, I found performance had dropped by about a third.
> I know that dispatch queues aren’t free, but I wasn’t expecting them to be this expensive! I’m not doing anything silly like wrapping dispatch_sync around trivial calls. The APIs I’m using it on do things like reading and writing values from the persistent store.
Approaching this naively, this result suggests that the block content, while not trivial, is too fine-grained — is divided too finely. For example, if you’re putting (essentially) one database read/write operation (or even a handful) in each block, perhaps that’s too small a unit of work for GCD. That idea is given *some* plausibility by the different outcomes on Mac and iPhone — a physical disk access is presumably much slower on average than an access to iOS persistent memory. (Of course, if your MacBook Pro is purely SSD, that might blow that idea out of the water. I don’t know how SSD access speeds compare to iOS memory.)
> Profiling shows that most of the time is being spent in thread/queue management or Objective-C refcount bookkeeping.
Unless I missed something, all of the responses in this thread went to the GCD issue. But if memory management is showing up “hot” like that too, there may be something else to investigate.
One option might be to look at what Instruments reports for the hotspots in terms of *counts* rather than times, and compare OS X with iOS. This would necessitate arranging things so you could get counts for known increments of work. If iOS gives comparable counts but much longer times, you will have one way of proceeding; if it gives much larger counts but similar or smaller times per count, you will have another way of proceeding.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden