• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Spinning the busy indicator
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Spinning the busy indicator
      • From: Graham Cox <email@hidden>
References: 
 >Spinning the busy indicator (From: Graham Cox <email@hidden>)
 >Re: Spinning the busy indicator (From: Quincey Morris <email@hidden>)
 >Re: Spinning the busy indicator (From: Graham Cox <email@hidden>)
 >Re: Spinning the busy indicator (From: Quincey Morris <email@hidden>)
 >Re: Spinning the busy indicator (From: Graham Cox <email@hidden>)
 >Re: Spinning the busy indicator (From: Quincey Morris <email@hidden>)
 >Re: Spinning the busy indicator (From: Graham Cox <email@hidden>)

  • Prev by Date: Re: Spinning the busy indicator
  • Next by Date: Re: Spinning the busy indicator
  • Previous by thread: Re: Spinning the busy indicator
  • Next by thread: Re: Spinning the busy indicator
  • Index(es):
    • Date
    • Thread