I’m writing an Objective-C API around a database library, and trying to add some optimizations. There’s a lot of room for parallelizing, since tasks like indexing involve a combination of I/O-bound and CPU-bound operations. As a first step, I made my API thread-safe by creating a dispatch queue and wrapping the C database calls in dispatch_sync blocks. Then I did some reorganization of the code so different parts run on different queues, allowing I/O and computation to run in parallel.
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. Profiling shows that most of the time is being spent in thread/queue management or Objective-C refcount bookkeeping. It looks as though adding GCD introduced a lot of CPU overhead, and the two cores on my iPhone aren’t enough to make up for that, while the eight cores in my MacBook Pro make it worthwhile. I tried backing out all the restructuring of my code, so there’s no actual parallelism going on, just the dispatch_sync calls. Predictably, performance is even worse; slightly more than half as fast as without them. So, I’m pretty disappointed. 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. I was expecting the cost of thread-safety to be lost in the noise compared to that. Any suggestions on what to try next? —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
