Also when you are using custom run loop sources (which is required here) pretty much all code that is interfacing the run loop is CF code, so no Objective-C method calls here (and the few remained ones can be IMP-cached so they are just as fast.)
Sent from my iPad > On Apr 27, 2014, at 5:36 AM, Jens Alfke <j...@mooseyard.com> wrote: > > >> On Apr 26, 2014, at 2:10 PM, ChanMaxthon <xcvi...@me.com> 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 (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
