Worth it for an object to cache its own IMPs?

[nat at mulle-kybernetik.com (Nat!)]

Am 02.03.2004 um 02:28 schrieb Scott Stevenson:

>
> On Mar 1, 2004, at 4:43 PM, Nat! wrote:
>
>> Shark is certainly nice but overly detailed at this point in time. 
>> Try Sampler.app.
>
> The problem I've encountered with sampler is that it collects all the 
> right data, but doesn't solve the visualization problem. It's a real 
> struggle to find the piece I'm looking for.
>
The ASCII report is fairly useful to me, if I get confused clicking 
through the browser.

>
>> Can you give a ballbark figure how many objects are involved (like 
>> 100000, a million) or so ?
>> How many objects are dynamically generated for each "operation" and 
>> if these are many, why is this necessary ?
>
> I ran everything through ObjectAlloc to try to get an idea. It's sort 
> of a fuzzy line between what Cocoa is using to support the UI elements 
> and basic functionality and what I'm using, but a single UI event (add 
> an object) took around ~1200 CFDicts and ~900 CFArrays.

> Starting up using a somewhat complicated data set (but tame compared 
> to what it will need to do) burns well over 100k collection objects, 
> but nowhere near 1 million.

Well over 100k objects is really a lot for Cocoa, especially if you are 
going to be touching them all often as you seem to be doing. This can 
be an indication that you should go to something more light weight, 
like C to reduce the complexity something around 10K Foundation 
objects. Without looking at your code, this is just pi-mal-daumen 
(fuzzy) advice. :)

>
> The mechanics are potentially quite complicated, and the idea has been 
> to burn some resources (less lines of code, more objects, more 
> recursion) to keep the implementation conceptually simple. I may have 
> to draw the line in certain areas, though.
	
>
>
>> Hmm.. searching should be fast. Why would this be slow ?
>
> At this point, I guess would sheer quantity of objects being 
> manipulated.

It's tough to give advice, without knowing the problem, but consider 
using some shadow NSMapTables or NSDictiories as indexes for your 
searches.

>
>
>>> It might also be that the autoreleased objects I'm getting back from 
>>> KVC could be piling up,
>>
>> Why are you getting autoreleased objects back from KVC ? This is 
>> unusual.
>
> The objects I get back from valueForKeyPath are retained/autoreleased, 
> or some equivalent, yes?

This would surprise me. It should just determine your accessor and call 
that.

> Not that KVC itself is doing it, but rather the objectAtIndex, 
> objectForKey, etc. methods than they boil down to.

If you ask your plain foundation arrays or dictionaries, they don't do 
that.

>
> Bottom line: I don't have to release a string I received from KVC when 
> it's dealing with a dictionary/array tree.
>

But neither would you if you were accessing it w/o KVC.

If you use KVC like this often and recursively like

	[obj valueForKeyPath:@"foo.bla"]

the KVC is probably doing

	components = [@"foo.bla" componentsSeparatedByString:@"."];
	while( ...)
      {
         obj = [obj valueForKeyPath:[components objectAtIndex:...]
      }

and this is going to be expensive. If you can lose the flexibility and 
just code

	[[obj foo] bla]

it will be much quicker.

Ciao
	Nat!
------------------------------------------------------
But didn't I always tell you, honey, if I just stayed
in place and I never spoke up, good things are bound
to happen ?  -- Jonathan Gems