Re: Why is indexOfObjectIdenticalTo: *far* faster than indexOfObject: ?
Re: Why is indexOfObjectIdenticalTo: *far* faster than indexOfObject: ?
- Subject: Re: Why is indexOfObjectIdenticalTo: *far* faster than indexOfObject: ?
- From: "M. Uli Kusterer" <email@hidden>
- Date: Thu, 23 Dec 2004 15:00:31 +0100
At 14:21 Uhr +0100 23.12.2004, Aurélien Hugelé wrote:
-(void)isEqual:(id)anObject {
if(anObject == self)
return YES;
if( ![anObject isKindOfClass:[self class])
return NO;
return [self
isEqualTo_PLACE_HERE_YOUR_OBJECT_:anObject]; //
specialized isEqual, depends of the object
internals, logic etc...
}
if all cocoa is implemented like that the
difference between isEqual: and " == " should be
quite minor (messaging overhead only)
what's your opinion ?
Well, I don't know RISC assembly, but in most
traditional assemblers, the == statement above
would evaluate to at most 3 instructions. If you
take the method call overhead as 3 instructions
(which it very likely isn't, it will probably
contain several == calls), the above code would
still consist of one == statement, plus 3 method
calls, plus one return statement. So this code
uses more than four times as many instructions as
the simple == statement.
And this is an optimistic estimation of the
overhead, and doesn't factor in cache latency, or
any of the other more involved bottlenecks, nor
what would actually happen inside
isEqualTo_PLACE_HERE_YOUR_OBJECT_:.
E.g. if there's an un-cached, un-hashed string
compare going on in that method, and you have
rather long strings, or very similar strings,
1000x doesn't sound too bad. Especially
considering OS X may be using UTF-16 characters
internally, which means a lot of data will be
shuffled to the CPU and back when comparing each
string.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden