Re: NSTreeController delete slowness...
Re: NSTreeController delete slowness...
- Subject: Re: NSTreeController delete slowness...
- From: "email@hidden" <email@hidden>
- Date: Fri, 2 Jan 2009 17:53:04 -0800
this if primarily for the archives, but its not a complete solution.
i've managed to improve the performance of deletes by a factor of
4-4.5 by simply calling:
-[NSTreeController setSelectionIndexPaths: nil];
prior to actually removing objects from my bound set. note that this
is still a little on the slow side (about .4 seconds to delete 603 of
610 top level objects in an outline view), but its sorta acceptable.
ken
At 3:50 PM -0800 1/1/09, email@hidden wrote:
i received the following advice off-list:
IIRC, when you do set operations like that, it performs a remove
for each item. Try making a mutable copy of the content set,
performing the set operation, and then setting the content of the
controller with the new set. That should wind up being faster as
only one KVO notification will be sent rather than 600.
so i tried this. and while setting the content of the treecontroller
directly did save a few milliseconds (of ~ 1.8 seconds), it did NOT
update the mutable set the treecontroller is bound to.
i also tried getting a mutable copy of the set the treecontroller is
bound to, removing the deleted objects from this set, and then
(re)setting the iVar holding the bound set. and this again saved on
a few milliseconds (of the ~ 1.8 seconds).
i've also tried unbinding the tree controller, deleting the objects
from my iVar set, and re-establishing the treecontroller's binding.
again, this only makes a difference of a few milliseconds (of the ~
1.8 seconds).
it still doesn't "feel right" to me that it should take ~1.8 seconds
to delete 603 top level objects from an outline that contains 610
top level objects. (fwiw, those 603 top level objects "contain" 1344
second level objects out of a total of 1399 total second level
objects).
i'm still hopeful someone can suggest something that will reduce
this time to something reasonable and/or suggest something i should
try.
thanx,
ken
At 2:21 PM -0800 12/30/08, email@hidden wrote:
i've got an NSOutlineView bound via an NSTreeController to a
mutable set in my model. in the sample i've been exploring, my
outline consists of 608 top level items in the outline, and only
goes one level deep. each top level item has 2 or more children,
and there are a total of 1393 children.
deletion can only happen for the top level objects, and when the
user deletes one or more of my items, i create a set of the objects
to be deleted and the call:
[myController removeProxySet: topLevelObjects];
the code for removeProxySet is:
- (void) removeProxySet: (NSSet*) inSet
{
[[self proxySet] minusSet: inSet];
}
where proxySet is simply the iVar mutable set in my controller that
has my model objects.
this all works fine and when the user asks to delete one or more
top level items, they appropriately disappear from the outline view.
however, it is rather slow!
when i looked at this with Shark, deleting just 2 of the top level
items spent 750 ms in [NSTreeController setContent], which is
called from Foundation NSKVOMinusSetAndNotify (in response to my
call of minusSet). if i delete ~600 of the top level items, it
takes 1.9 seconds! there are obviously some calls to some of my
code to access values for the various columns of the outline view,
but the overwhelming majority of the time is spent in app kit and
foundation code, mostly in tree controller and friends.
this is on a 3GHz MacPro with 6G of memory and a total of 4 cores.
i don't believe the disk is being hit for any of this.
(fwiw, i obtained my numbers by putting shark into remote mode and
simply starting and stopping it when deleting my items.)
this seems unreasonably slow to me. i realize that i'm not posting
very much code, but since so little of my code seems to be involved
in the slowness, i didn't think it really relevant. should i be
doing something other than removeProxySet and minusSet?
thanx,
ken
_______________________________________________
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