On 14 Nov 2010, at 16:16, James Bucanek wrote: > NSOperationQueue uses Grand Central Dispatch, which will attempt to > load-balance the number of running operations based on _CPU_ resources. > However, that doesn't mean GCD will (or even can) automatically find the most > efficient run schedule for your code.
Ok, understood. >> My question: how can I ensure that no more operations are launched at any one >> time than the system can handle? > > -[NSOperationQueue setMaxConcurrentOperationCount:] My bad. I wasn't totally clear in my description there. I actually already deploy that as a user definable option, and it certainly works. (Or, well, a tester just told me that if he specifies more than 9 operations, then the limit doesn't work. I'll have to check that out. Might be some silly mistake of mine. Don't know yet.) I was thinking along the lines of how I can ensure that the system knows that launching more tasks concurrently would be a bad thing when resources are already being maxed out. Ken's answer provides some very useful deeper info on the hows and whys here. > Personally, if your operation is mostly I/O bound, the best solution is to > set maxConcurrentOperationCount to 1 and run the operations sequentially. The > biggest problem in trying get better performance from I/O heavy processes is > the HD trashing that occurs when you have more than one working > simultaneously. This can easily mean that two operations will run slower than > one. I know from testing that running more than one operation can be quite beneficial, but the operations are I/O heavy, especially at the end, so this may well be a factor, where the sweet spot lies around a low number of concurrent operations. The sweet spot may of course differ on different machines and systems, so that is where setMaxConcurrentOperationCount comes in handy. Thanks for all the useful info. António ---------------------------------------------------- It is better to light a candle than to curse the darkness ---------------------------------------------------- _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
