On 17-Apr-10, at 9:14 AM, Paul Sanders wrote:
> Yep, it's a big win. Even if the default allocator does something
> similar (and I think you're right that a linked list of free
blocks of
> a given size is maintained by the malloc code, or something of that
> sort), this scheme avoids a fair handful of method calls and
function
> calls per object, and so it wins big even just with that. I can't
> remember what the degree of speedup was (I put this scheme in
several
> months ago now), but it was quite substantial.
http://www.mikeash.com/pyblog/performance-comparisons-of-common-operations.html
According to which, alloc + init + release costs about the same as
35-40 method calls.
Right, exactly. Every time I reuse one of my objects I avoid all
that. That's more method calls per object than will probably happen
over the whole rest of their lifetime. It was a huge speedup when I
put this recycling scheme in; I want to say more than double the
speed, but I did this a while ago now and don't remember precisely.
The code I posted could cache [MyClass class] if (as I do) you like
to leave the asserts in your release code. And it works, of course,
because the isA pointer in all instances of a particular class is
the same.
As I mentioned in my post to Graham just now, doesn't your
implementation assume that NSObject's only ivar is the isa pointer,
though? Is that guaranteed somewhere, as Graham asserted? If it is,
then that's fine...
Ben Haller
McGill University
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
