Worth it for an object to caching its own IMPs?

[sstevenson at mac.com (Scott Stevenson)]

On Mar 1, 2004, at 3:37 PM, Nat! wrote:

>> I'm in a situation where an object is calling methods on itself 
>> frequently and latency is important.
>
> So what kind of speed do you need, and what kind of speed are you 
> getting at the moment ?

I'm not quite sure how to answer that. Something that I'd hope would 
take < 1 sec is taking > 5 seconds. I'm fairly new to the performance 
tools but I have read up on Shark. I've also read your stuff, which is 
what inspired me to try IMP caching in certain places.

There's a lot of object spawning, memory allocation/deallocation, 
method dispatches, etc. A little bit of everything. The engine is 
generalized so it has to make a lot of decisions on the fly, and the 
nsarray/nsdict tree currently serves as the decision map.

What I need is faster retrieval of strings from a structure. They don't 
necessarily have to be NSStrings, but that would be more convenient 
(obviously). Right now, I'm thinking the best approach is to drop 
objects altogether for the core engine. I'm considering recreating the 
tree with c data structures, or maybe implementing some sort of simple 
rule system.

I've also considered creating a second representation of the tree which 
is a simple flat NSDictionary, keyed by the actual keypath. So instead 
of this:

	[myStructure valueForKeyPath:@"element1.element2.element3"];

I do this:

	[myStructure objectForKey:@"element1.element2.element3"];

Not sure offhand how much time this would save, but 30% less dispatches 
has to be worth something. I can simply build up the cache at startup. 
I could also take this same concept and make it some sort of c 
structure to buy even more speed, but I'd still have to do some 
nsstring > utf8 various certain places.

Thanks,

    - Scott

--
Tree House Ideas
http://treehouseideas.com/