Re: Speed Traps
Re: Speed Traps
- Subject: Re: Speed Traps
- From: Marcel Weiher <email@hidden>
- Date: Mon, 19 May 2003 12:13:16 +0200
On Monday, May 19, 2003, at 02:20 Uhr, Kevin Elliott wrote:
At 21:51 +0200 on 5/16/03, Marcel Weiher wrote:
The way autoreleases pools are implemented is (essentially) as a
list of objects (it would be very easy to implement them using
NSMutableArray, but I don't know if they are done that way).
I am not so sure that retaining the objects in the autorelease pool
(which is >what NSMutableArray would do) is such a good idea...
Why?
Because adding an object to a pool should be retain-count neutral.
Yes, it would still sort of work, but, for example, finding
over-releasing would be even more difficult.
Apples docs on the performance of Autorelease pools is somewhat
misleading (in my opinion). If you don't allocate anymore objects
than you "normally" would the performance is nearly the same as for
manually calling release.
This turns out not to be the case. I have done extensive
benchmarking of >various aspects of Cocoa memory management,
including allocation, deallocation, >reference counting and pools.
Autorelease pools are significantly slower than a plain retain. Of
course, NSObject's extra-reference count implementation is so
incredibly slow that the difference isn't all that noticeable, but if
you've implemented an inline refcount or are using one of the
built-in classes, then the difference is very signiifcant.
With all due respect, how is "the performance is nearly the same" very
different than "the difference isn't all that noticeable"?
It is "very different" in that the difference is ONLY not all that
noticeable if you use NSObject's brain-dead refcount implementation,
which is in itself several times slower than an inline reference count
(almost 10 times for an optimized inline refcount). The reason it is
so slow is that every refcount operation requires a hash lookup and
possibly allocation/deallocation of the slot for the extra-refcount
inserted into the table. Nobody in their right mind uses that,
certainly Apple doesn't. All Apple-provided classes use some sort of
inline refcount.
Yes, there is a performance difference and if you, for whatever
reason, do your own memory management it may become noticeable. But
in the standard situation the performance is the same.
No, because in the standard situation you use a lot of Apple's objects,
which all do the inline refcount. And quite frankly, I find it
somewhat disingenuous that Apple doesn't point out how important doing
this is.
For example, the "autoreleasing accessor" that is sometimes
recommended by Apple happens to be roughly 10 times slower than the
"canonical accessor" that just about everyone else recommends.
Yes it's slower. I'm not sure I buy 10 times slower, and I'd like to
see how it was benchmarked.
This should be in the list archives. Refreshing my memory, the
10-times figure was for the "get" accessor, where the canonical method
just returns the instance variable, and the "autoreleasing" accessor
does a retain/autorelease. So the time for the plain accessor is
really just the messaging overhead. The difference goes up to factor
50 when you use IMP-caching...
So while the factor 10 does apply to the "autoreleasing accessors
considered harmful" discussion it doesn't apply quite the same to the
difference between release and autorelease.
For NSObject, the difference between retain + release and retain +
autorelease is still around 40%, for NSString it is roughly a factor 2.
A faster inline refcount like MPWObject's brings this to roughly a
factor 3-4.
Just to put these relative numbers into perspective: a retain +
release for an MPWObject takes 170 ns on a 1GHz G4. An NSObject retain
+ autorelease takes 1400 ns.
Apple's argument is based purely on stability, not speed, in which
case it probably wins.
Nope. This claim has been thoroughly debunked. Code does not get more
stable through obfuscation.
But again the point of all this is that his autoreleasing version is
NOT faster than his manual release code.
Yup, which is interesting.
He's simply not including the deallocate time in his autorelease
version.
Exactly. And actual object creation/destruction times dwarf
refcounting times, except for NSObject.
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.
_______________________________________________
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.