Just because you are using Core Foundation interfaces doesn’t mean you aren’t 
getting Objective-C code behind the scenes.

On Apr 26, 2014, at 2:44 PM, ChanMaxthon <xcvi...@me.com> wrote:

> 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/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


_______________________________________________

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

Reply via email to