[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Worth it for an object to caching its own IMPs?



Am 02.03.2004 um 01:22 schrieb 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.

Well that's the answer I was looking for.

> 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.

Shark is certainly nice but overly detailed at this point in time. Try 
Sampler.app. IMP caching pays off mostly, if the cached method is not 
doing much (-> 
http://www.mulle-kybernetik.com/artikel/Optimization/opti-3.html (I 
think))

>
> 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.
>

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 misspoke when I said "parsing." What I really meant was finding an 
>> object somewhere in an arrary/dict tree. I didn't expect imp caching 
>> would be a replacement for changing the implementation, just wanted 
>> to see what it would do.

Hmm.. searching should be fast. Why would this be slow ?


> 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.

>
> 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.

Probably a smart move if you want close to optimal performance and have 
some time to invest.

Ciao
	Nat!
------------------------------------------------------
"It's always easier to ask forgiveness than it is to
get permission." -- Rear Admiral Hopper