Article:		Knowing When to Let Go: Better Living Through Memory Management
Subject:		is simpler slower?
Date:		2003-06-12 22:07:15
From:		iapole
Response to: is simpler slower?
Completely subjectively--yes. In the example accessor method I gave (which is not the only possible one, as I'll show in a moment), the penalties are as follows: - one 4-byte word for the pointer (id old) - two messages, both of which will have been optimized by Apple considering how commonly they're called - one assignment. In the example you show here, you have the same except for the pointer to the object, but the difference in message (autorelease as opposed to release) will make a much larger difference. For one thing, in order to autorelease the object, the autorelease pool has to know it exists--that is, it has to use a pointer to it of its own. And as I discussed in the article, autoreleasing is a slow operation. Therefore, I would recommend against autoreleasing in this context unless you have some very specific reason to. As another example of an accessor, how about: -(void)setFriend:(id)aFriend { [friend release]; friend = [aFriend retain]; } Note that none of these examples make any attempt at addressing concurrency. I recommend reading http://www.cocoadev.com/index.pl?AccessorMethods for more insight into Cocoa accessor methods, including thread-safe accessors.

Showing messages 1 through 5 of 5.

• is simpler slower?
  2003-06-20 18:05:46  anonymous2 [View]
  
  
  "I recommend reading http://www.cocoadev.com/index.pl?AccessorMethods for more insight into Cocoa accessor methods, including thread-safe accessors."
  
  The more complete article it references is at:
  
  http://www.stepwise.com/Articles/Technical/2002-06-11.01.html/
  
  That in turn references another more general introduction to memory management
  
  ...
  
  mmalc

• is simpler slower?
  2003-06-13 14:27:00  anonymous2 [View]
  
  
  one thing to worry about when using the accessor method you suggested in your post is the situation where the same object passed to the method was already the one set! calling retain on aFriend could then potentially result in a call to a nonexistent object.
  
  
• is simpler slower?
  2003-06-13 20:52:04  iapole [View]
  
  
  There, I knew there was a good reason not to use it! Thanks, I just couldn't remember it for the life of me.
• is simpler slower?
  2003-06-15 21:29:50  anonymous2 [View]
  
  
  Perhaps this would be faster?
  
  -setFriend:(id)aFriend
  {
  if (aFriend != friend)
  {
  [friend release];
  friend = [aFriend retain];
  }
  }
  
  I suppose it depends on the efficency of the comparison operation.
• is simpler slower?
  2003-06-16 16:11:16  iapole [View]
  
  
  I believe the PPC's branch prediction is good enough to make that fast, but faster still will probably be:
  
  -(void)setFriend:(id)aFriend
  {
  [aFriend retain];
  [friend release];
  friend = aFriend;
  }
  
  Which avoids the releasing problem. But keep in mind that this is all subjective, I have done absolutely no tests of efficiency regarding these.