In addition to GCD which is a good idea, you might look into the Accelerate framework to see if it offers something. There's a fairly recent WWDC video about it.
Sent from my iPhone > On 2015/05/01, at 14:53, Graham Cox <graham....@bigpond.com> wrote: > > >> On 1 May 2015, at 3:28 pm, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >> >> ― I don’t see anything really wrong at any point, other than it looks >> unresponsive because it’s very busy for a while. > > Well, thanks for having a look and taking an interest - and apologies for the > rather scrappy coding. > >> >> I would suggest you use QoS to lower the priority of your calculations. This >> will let UI updates and other important main thread stuff go through ahead >> of the calculations. The calculations should probably be at the lowest or >> second-lowest QoS level. > > > I must admit I hadn’t given any thought to the QoS - just learning my way > around this stuff. > > So, the docs say (ha! here we go again…) that the default QoS is > NSOperationQualityOfServiceBackground. This appears to be the LOWEST QoS > constant. However, it also states that it is only used if the NSOperation > itself doesn’t set this value, but because addOperationWithBlock: creates its > own NSOperation internally (that we mere mortals don’t get to access), it > might be assigning a value that overrides this. Unhelpfully, the simple CPU > usage view in XCode only states "QoS unavailable”. > > It looks as if to be sure I’m going to have to drop down a level and create > my own NSOperations. > > >> Lowering the QoS might take care of your problem, but if it doesn’t, you’re >> faced with some decisions about “number of threads to use”. If it comes to >> this, I wonder if it’s a mistake in this case to let the processing fall >> through to GCD like you’re doing. You have so much processing to do, it’s >> going to impact the system badly if you tell the system to get it done as >> fast as possible. This *may* be a case where you create your own pool of >> NSThreads (either the number of logical CPUs or one less than that), and >> parcel the work out to them, so that it can’t get out of hand. (However, you >> might still use NSOperationQueue to manage things for you, but instead of an >> individual NSOperation doing the work, it would give the work to a NSThread >> in your pool.) > > I reckon if it comes to that there’s probably going to be very little value > left in NSOperationQueue so I may as well just use the GCD API directly. But > I’ll experiment a bit more… > > > ―Graham > > > > _______________________________________________ > > 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/dangerwillrobinsondanger%40gmail.com > > This email sent to dangerwillrobinsondan...@gmail.com _______________________________________________ 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
