Re: Spinning the busy indicator
Re: Spinning the busy indicator
- Subject: Re: Spinning the busy indicator
- From: email@hidden
- Date: Fri, 01 May 2015 15:10:53 +0900
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 <email@hidden> wrote:
>
>
>> On 1 May 2015, at 3:28 pm, Quincey Morris <email@hidden> 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 (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