Ken Thomases <mailto:[EMAIL PROTECTED]> wrote (Tuesday, August
5, 2008 9:34 PM -0500):
On Aug 5, 2008, at 10:20 PM, James Bucanek wrote:
First rule of optimization: Don't!
Get the code working and profile it. Then if, and only if, it's a
significant performance bottleneck THEN consider optimizing it.
Fine advice.
However, checking whether a class responds to a selector is not "an
optimization" in the way you're suggesting. That is, it's not bending
over backwards to use an obscure technique just to avoid the assumed
cost of some operation. In my experience, it's the more common idiom
compared to using exception handling to cope with the case where an
object does not respond.
In retrospect, I won't argue the point. The discussion got off
on a bit of a tangent. I was really just trying to demonstrate
an alternate method of discovery. I wasn't advocating exceptions
over introspection.
... and speaking of getting off topic ...
The try/catch setup is well optimized and introduces very
little overhead. So in the nominal case, where there is no
exception, there's almost no overhead at all. Even if an
exception was thrown, NSException is fairly lightweight.
This is not particularly accurate.
There, I'll beg to differ.
Exception handlers are cheap ("zero-cost") to set up in C++ and in the
64-bit Objective-C runtime. They are unfortunately kind of expensive
to set up in 32-bit Objective-C. They are based on setjmp/longjmp.
setjmp/longjmp is very fast. Or at least it used to. I
understand that setjmp has slowed down over the years as more
and more state information needs to be saved to make it work.
During my career I've implemented setjmp/longjmp a few times and
it used to take only about a dozen machine instructions to
squirrel away the current stack pointers into a local structure,
return, and perform a conditional test. Probably faster than objc_msgSend.
I haven't measured it in ages, but I suspect that it's still
reasonably fast. I have several performance intensive
applications that I profile regularly, and my code uses
exceptions and try/catch blocks a lot. I've never seen setjmp or
longjmp show up in Shark as a hot spot. So from casual
observation, I'd say that try/catch blocks don't slow things
down too much.
Setting up the handler is almost surely more expensive than checking
if the superclass responds to the selector.
I stopped guessing about performance years ago. Profile it and
let us know. ;)
--
James Bucanek
_______________________________________________
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 [EMAIL PROTECTED]
