Re: narraycontroller sort performance problems
Re: narraycontroller sort performance problems
- Subject: Re: narraycontroller sort performance problems
- From: Richard <email@hidden>
- Date: Fri, 18 Dec 2009 16:30:10 +0100
hey mike
the final thought put me on to an easy solution, thanks. i just stopped the
controller automaticallly rearranging the content, then called
[arrayController rearrangeContent] after a batch of search results has
arrived. it still is quite heavy on the processor, but the results arrive in
a timely fashion and the ui does not freeze, so good enough i think.
On Thu, Dec 17, 2009 at 11:29 PM, Mike Abdullah
<email@hidden>wrote:
> Aha, now we're talking!
>
> So the problem is that after ever change to your model, the controller must
> rearrange its content to match. It knows the change is needed because it
> receives a Key-Value Observing notification of the change. It's got no way
> to know that more changes are about to happen again very shortly and so
> shouldn't bother rearranging just yet.
>
> Ways to fix:
>
> A) Implement manual KVO notifications so that you can do:
> 1. willChangeValueForKey:…
> 2. Make all the changes in one go
> 3. didChangeValueForKey:…
>
> B) Temporarily unbind the controller, make your changes, rebind it.
>
> C) Make your changes using the controller's own methods.
> -insertObject:atArrangedObjectsIndex: etc. It's intelligent enough to know
> not to rearrange the entire content.
>
> Final thought, is -automaticallyRearrangesObjects set to YES? I think if
> that is turned off, the controller won't need to observe every single object
> in the array.
>
> On 17 Dec 2009, at 19:30, Richard wrote:
>
> > jens, this sounds reasonable, i will give it a try.
> >
> > mike, i did give it a shot in instruments, comparing the same search with
> > and without sorting. i'm not really sure what to make of the results
> > however. when sorting is enabled, nearly all the execution time is taken
> up
> > with [NSArrayController setContent:] with the time shared evenly over
> > [NSObject removeObserver] and [NSObject addObserver], with only a small
> > fraction of the time taken up by actual sorting.
> >
> > so, it would seem that the extra workload is in the array controller
> > stopping observing the old content, then reobserving the new content. not
> > sure what can be done to alleviate this, any suggestions?
> >
> > On Thu, Dec 17, 2009 at 5:50 PM, Mike Abdullah <
> email@hidden>wrote:
> >
> >> As with every performance question. Don't "assume", MEASURE. Fire up
> >> Instruments and find out what is using up the CPU.
> >>
> >> On 17 Dec 2009, at 15:22, Richard wrote:
> >>
> >>> hey
> >>>
> >>> i have an app that performs searches over a network connection. the app
> >> uses
> >>> core data to manage all the search requests (currently using an in
> memory
> >>> store), with an array controller and table view bound to the relevant
> >>> results. a search query produces up to about 10000 results, and they
> are
> >>> added to the data model in batches of 10 or so. this all works well,
> >> until i
> >>> add sorting to the array controller. i then find that the CPU use of
> the
> >>> application stays at 100% and things go pretty slowly from that point
> on.
> >>>
> >>> i assume this is because with each new search result that is being
> >> retrieved
> >>> and added to the core data model, the array controller is resorting the
> >>> entire collection of search results? can anyone suggest a solution to
> >> this
> >>> problem?
> >>>
> >>> thanks
> >>> _______________________________________________
> >>>
> >>> 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
>
>
_______________________________________________
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