On Apr 26, 2014, at 2:10 PM, ChanMaxthon <[email protected]> wrote: > Since you are interfacing with database maybe you can use a little > transaction interface which is its own thread and run loop. That may be able > to cut down your amount of syscalls. That is, not using GCD but old fashioned > NSThread, NSRunLoop (and CFRunLoop) and NSCondition.
I’m pretty sure NSRunLoop has more overhead than a dispatch_queue does. It’s doing more work and it’s using Obj-C messaging. > OS X implemented GCD at kernel level which introduced lots of syscalls which > are super expensive. The old school method is largely user land so it may > help a little by keeping syscalls to a minimum. @synchronized uses > Objective-C runtime functions which was once code behind those old school > classes. That's the opposite of what the docs say: "A dispatch semaphore works like a traditional semaphore, except that when the resource is available, it takes less time to acquire a dispatch semaphore. The reason is that Grand Central Dispatch does not call into the kernel for this particular case. It calls into the kernel only when the resource is not available and the system needs to park your thread until the semaphore is signaled.” —Concurrency Programming Guide —Jens _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
