Hi,
On 1/19/07, Quentin Mathé <[EMAIL PROTECTED]> wrote:
Le 18 janv. 07 à 14:59, David Chisnall a écrit :
> This would give us a mechanism for very quickly creating objects
> that have a very short lifecycle. Is it interesting?
I don't really know. Many optimizations will often be available
before switching to such "unusual" object management. Most of object
oriented languages always put objects on the heap, so developers are
inhabited to it.
I started playing a bit with the idea... I wrote a stupid micro
benchmark -- a Test object with an int and a float as ivars, and a
method that simply assign a value to the ivars.
I then creates 10000000 objects in a loop, initialize them, call the
method, and release immediately the object.
Without optimizations: ~4.10s (on a macbook pro 2.16Ghz, core duo)
Using a custom NSZone: ~4.2s (!!!)
Caching method calls: 2.77s
Caching method calls + custom zone: 2.72s
So apparently, the default memory management (at least on cocoa) isn't
that bad, and while very likely I didn't use it properly, it's obvious
that the biggest gain comes from caching method calls. With memory
access as fast as it it nowadays, I'm thinking that custom zones are
probaby not interesting anymore, even if they were very precious back
in 1991 on a NeXT machine.
Ok now... here's the interesting bit of the mail :)
I translated this stupid little class into C++ and applied the same
stupid benchmark:
Objects created on the stack: 0.24s
Objects created on the heap: 1.37s
Our beloved ObjC is completely out of its league if you use the
stack... So is everything lost ? no :) you can abuse the objc runtime
:D and creates objc objects on the stack as well :)
ObjC objects created on the stack: 0.23s (!!)
ObjC objects created on the stack + cached imps: 0.13s (!!!)
:D
Again, it's only a micro-benchmark of a very simple case, and probably
doesn't mean that much; though it seems to me that if you really
want/need it, you can have performances very close to C++.. (if not
better sometimes :D)
Of course, the problem by creating objects on the stack is you loose
some dynamicity; for instance you can't use NSNumber as it is a class
cluster -- you can only use concrete classes. Also, your dealloc
method shouldn't call [super dealloc] as it will then try to
deallocate the object at some point, which isn't necessary as it's on
the stack. But that's a minor inconvenient (you can easily split your
dealloc code into a cleanup method that you can call explicitely when
using objects on the stack, and the normal dealloc method would call
this cleanup method in normal use).
Oh, here is the macros I used to create objects on the stack:
#define STACKCLASS(class) typedef struct { @defs(class) }
__CLASS_ON_STACK__ ## class;
#define STACKOBJECTISA(objectName,className,classIsa)
__CLASS_ON_STACK__ ## className objectName; objectName.isa = classIsa;
#define STACKOBJECT(objectName,className)
STACKOBJECTISA(objectName,className,[className class]);
an example:
STACKCLASS(Test);
int i;
for (i=0; i<100; i++)
{
STACKOBJECT(stest,Test);
id test = (id)&stest;
[test init];
[test plop];
}
You can get the class isa beforehand and use STACKOBJECTISA to gain
one method call too.
Here is the macros I used for caching imps:
#define CALLIMP(imp,object,sel,args...) (*imp)(object, @selector(sel), args)
#define CALLIMPN(imp,object,sel) (*imp)(object, @selector(sel))
You use them like that:
IMP imp1 = [Test methodForSelector:@selector(alloc)];
id p = [Test new];
IMP imp2 = [p methodForSelector: @selector(init)];
IMP imp3 = [p methodForSelector: @selector(plop)];
IMP imp4 = [p methodForSelector: @selector(release)];
[p release];
int i;
for (i=0; i<100; i++)
{
id test = CALLIMPN(imp1, c, alloc);
CALLIMPN (imp2, test, init);
CALLIMPN (imp4, test, plop);
CALLIMPN (imp3, test, release);
}
--
Nicolas Roard
"I love deadlines. I like the whooshing sound they make as they fly
by." -- Douglas Adams
_______________________________________________
Etoile-dev mailing list
[email protected]
https://mail.gna.org/listinfo/etoile-dev
