Re: Spinning the busy indicator
Re: Spinning the busy indicator
- Subject: Re: Spinning the busy indicator
- From: Quincey Morris <email@hidden>
- Date: Fri, 01 May 2015 05:28:17 +0000
On Apr 30, 2015, at 21:46 , Graham Cox <email@hidden> wrote:
>
> If anyone’s interested in having a look at what’s happening, I’ve put the project sources up here: http://apptree.net/code/Gingerbread.zip <http://apptree.net/code/Gingerbread.zip>
Here’s what I see:
— I took out your 3-thread limitation.
— I’m running on a 4-core i7, so there are 8 logical CPUs, and it uses 8 threads for each “run”.
— I see the progress indicator appear, stop spinning for a while, spin for a while and disappear. It seems clear that it stops spinning simply because the CPUs are busy doing other things. I’m almost certain this is a red herring (though a UI issue, a point I’ll come back to).
— It takes several seconds to recalculate/redraw the view. Then it takes another few seconds for the CPUs to go idle. It looks like there’s a lot of catching up/cleaning up going on after its finished. Perhaps there’s a pile of delegate notifications pending? You really should look into this via Instruments.
— I don’t see anything really wrong at any point, other than it looks unresponsive because it’s very busy for a while.
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.
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.)
_______________________________________________
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