Re: NSOperation Efficiency
Re: NSOperation Efficiency
- Subject: Re: NSOperation Efficiency
- From: Kyle Sluder <email@hidden>
- Date: Tue, 04 Dec 2012 20:41:55 -0800
On Dec 4, 2012, at 8:00 PM, Jens Alfke <[1]email@hidden> wrote:
On Dec 4, 2012, at 7:33 PM, Kyle Sluder <[2]email@hidden> wrote:
Yeah, it sounds like you're saturating the thread pool due to
non-CPU-bound operations. NSOpQ is going to spend its entire time
spawning and switching to threads while you append more and more
operations to the queue.
Apologies, but I have trouble believing that. Isn’t NSOperationQueue
just a thin veneer around GCD? A few thousand tasks shouldn’t cause a
performance problem. What’s your evidence that it does?
NSOperationQueue uses KVO for dependency tracking and queue width
management. In 10.7, the implementation was apparently changed to thunk
all KVO ops onto the main thread; I'm guessing this fixed a bug by
serializing all state changes. It also slowed down enqueueing
operations onto our NSOperationQueue from a background thread by a
factor of ten or more. I have samples to prove it.
Also, if a worker thread gets blocked, GCD is happy to spin up another
one. It has no concept of queue width; NSOpQ builds this atop GCD. If a
worker thread blocks executing a task from a concurrent queue, GCD will
happily spin up another thread, potentially exhausting your thread pool
and leading to deadlock or other resource contention. Doug Russell from
Black Pixel has written a proof-of-concept implementation of queue
widths for GCD that addresses this
issue: [3]https://github.com/rustle/QueueWithWidth
For an example of how GCD will happily exhaust your thread pool if you
feed it an avalanche of non-CPU-bound tasks, check out Mike Ash's
invaluable
blog: [4]http://www.mikeash.com/pyblog/friday-qa-2009-09-25-gcd-practic
um.html
--Kyle Sluder
References
1. mailto:email@hidden
2. mailto:email@hidden
3. https://github.com/rustle/QueueWithWidth
4. http://www.mikeash.com/pyblog/friday-qa-2009-09-25-gcd-practicum.html
_______________________________________________
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