Re: Problems with Key Observing Registration Performance
Re: Problems with Key Observing Registration Performance
- Subject: Re: Problems with Key Observing Registration Performance
- From: Seth Willits <email@hidden>
- Date: Wed, 10 Sep 2008 01:57:45 -0700
On Sep 10, 2008, at 1:04 AM, Markus Spoettl wrote:
On Sep 9, 2008, at 9:36 PM, Seth Willits wrote:
Surely adding 330 items to an array shouldn't take a minute on any
machine from this century. I think your code is doing something
you're not realizing. You could:
a) have a method that on each observation explicitly creates a
bajillion objects
b) have a bajillion observers that each create a bunch of objects
c) have enough observers and have enough oddly placed observations
and method calls that you literally end up calling the same methods
over many many times because it recurses unintentionally, for each
object added to the array.
It might very well be something I don't realize. Shark tells me that
all the time is spent in AppKit and Foundation, not in my code. (I
can email the Shark session if you're interested, its 3.8 MB).
At the center of the problem (judging from the shark call stack) is
NSCollectionView which causes all those burned cycles. If that
collection view is swapped out and replaced by NSOutlineView, the
whole thing gets very snappy. Of course there's no custom NSView and
registering observers going on then.
I have had a lot of speculation following here but there's no point
for that. Fact is as soon as I add observers to the objects that are
being represented by the collection view, things get excruciatingly
slow.
If you can reproduce it in a simple enough example to share the code,
I'd be interested in taking a look.
--
Seth Willits
_______________________________________________
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