Re: Speed Traps
Re: Speed Traps
- Subject: Re: Speed Traps
- From: Tom Sutcliffe <email@hidden>
- Date: Mon, 19 May 2003 23:31:39 +0100
Ah I think I see - so NSObject keeps a static hashtable of all the
NSObject instances whose retain count is greater than one? Bizarre but
the more I think about it the more it makes sense. I presume that
object instances are the keys and the retain count the values then?
Out of interest could you use poseAsClass on NSObject and stick in your
own inline implementation instead, if you really wanted that behaviour
on all your subclasses without having to code it into each of them
separately?
[reads docs more carefully and does some experimenting]
the docs say you can't add instance variables to the class that is
posing, and yes everything stops working if you try it. Offsets messed
up I suppose. Is there a spare byte anywhere in NSObject's instance
variables that could be pinched for a reference count? I suppose it
would undermine the whole reason for using a global hashtable if there
was :)
Thanks,
Tom
On Monday, May 19, 2003, at 10:36 pm, publiclook wrote:
The common case for instances is that the retain count is exactly one.
NSObject's use of a hash table to store retain counts is a memory
optimization so that in the common case, no extra memory is required
to store a retain count. In other words, if an NSObject instance has
a retain count of one, it is not stored in the hash table and no
memory is required to store a retain count. If NSObject had an
instance variable to store retain counts, then every single instance
would require 8 bytes instead of 4. NeXT/Apple optimized memory usage
to half in the common case in exchange for a slight performance hit in
unusual cases.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.