• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: GCD killed my performance
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GCD killed my performance


  • Subject: Re: GCD killed my performance
  • From: ChanMaxthon <email@hidden>
  • Date: Sun, 27 Apr 2014 05:10:20 +0800

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.

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.

Sent from my iPad

> On Apr 27, 2014, at 4:55 AM, Quincey Morris <email@hidden> wrote:
>
>> On Apr 26, 2014, at 12:02 , Kyle Sluder <email@hidden> wrote:
>>
>> FWIW, I’ve been of the opinion for a while that including dispatch_sync in the API was a mistake.  Too often it becomes a crutch used without understanding, resulting in stop-start behavior across threads or cores.
>
> I don’t know if you’ll agree, but it seems to me that there’s a distinction between a *locking* mechanism such as @synchronized, and a *queuing* mechanism, which Jens seems to have demonstrated dispatch_sync to be.
>
> I understand that both mechanisms may at a lower level depend on both queues and locks, but the distinction I’m making is that a locking mechanism is used when we hope that the lock will generally be granted without contention, while a queuing mechanism is used when we expect there will generally be some contending operation in progress.
>
> _______________________________________________
>
> 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

_______________________________________________

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


  • Follow-Ups:
    • Re: GCD killed my performance
      • From: Jens Alfke <email@hidden>
References: 
 >Re: GCD killed my performance (From: Jonathan Taylor <email@hidden>)
 >Re: GCD killed my performance (From: Jens Alfke <email@hidden>)
 >Re: GCD killed my performance (From: Seth Willits <email@hidden>)
 >Re: GCD killed my performance (From: Kyle Sluder <email@hidden>)
 >Re: GCD killed my performance (From: Quincey Morris <email@hidden>)

  • Prev by Date: Re: GCD killed my performance
  • Next by Date: Re: GCD killed my performance
  • Previous by thread: Re: GCD killed my performance
  • Next by thread: Re: GCD killed my performance
  • Index(es):
    • Date
    • Thread