• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Using performSelector: on super
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using performSelector: on super


  • Subject: Re: Using performSelector: on super
  • From: Ken Thomases <email@hidden>
  • Date: Tue, 5 Aug 2008 23:34:51 -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 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@hidden)

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:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Using performSelector: on super
      • From: James Bucanek <email@hidden>
References: 
 >Re: Using performSelector: on super (From: James Bucanek <email@hidden>)

  • Prev by Date: Re: How to use a button to update an application with a text field value
  • Next by Date: Re: NSDocument opening folders
  • Previous by thread: Re: Using performSelector: on super
  • Next by thread: Re: Using performSelector: on super
  • Index(es):
    • Date
    • Thread