On Apr 30, 2015, at 21:46 , Graham Cox <graham....@bigpond.com> 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 (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

Reply via email to