Re: GCD killed my performance
Re: GCD killed my performance
- Subject: Re: GCD killed my performance
- From: ChanMaxthon <email@hidden>
- Date: Sun, 27 Apr 2014 05:44:42 +0800
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 <email@hidden> wrote:
>
>
>> On Apr 26, 2014, at 2:10 PM, ChanMaxthon <email@hidden> 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@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