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 other words, quite aside from any consideration about optimization,
I don't see the advantage of using the exception-handling approach
over the more common checking-if-responds approach.
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. 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.
Setting up the handler is almost surely more expensive than checking
if the superclass responds to the selector.
So unless you're calling -close a million times I seriously doubt
it's going to cause a performance problem.
Well, that's true. Almost anything you do rarely is cheap on modern
computers.
Still, I think using exceptions rather than checking if something
responds to a selector is bad advice.
Even more so, writing code to cope with uncertainty about the features
of one's superclass seems like asking for trouble. Is it really the
case that OP can't rely on the implementation of his superclass? I
mean, if you're not sure whether SuperSocket provides a -close method,
how can you be sure that, if it is there, it does what you intend?
You're invoking a method in nearly complete ignorance about what it
might do.
Cheers,
Ken
_______________________________________________
Cocoa-dev mailing list ([email protected])
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]
