Re: I think I get most of the memory stuff but...
Re: I think I get most of the memory stuff but...
- Subject: Re: I think I get most of the memory stuff but...
- From: Marco Scheurer <email@hidden>
- Date: Mon, 5 May 2003 16:03:14 +0200
On Monday, May 5, 2003, at 11:04 AM, Sherm Pendley wrote:
On Monday, May 5, 2003, at 03:32 AM, Scott Anguish wrote:
On Monday, May 5, 2003, at 02:27 AM, Jeffrey Mattox wrote:
I like that sequence better, but what if aString and clientCode are
the same object, as Tony pointed out? Would it work to do it this
way (use autorelease instead):
-(void)setClientCode:(NSString *) aString {
[clientCode autorelease];
clientCode = aString;
[clientCode retain];
}
It's better to retain and then release rather that autorelease and
then retain.
autorelease is slower, and if you don't need it to stick around, why
autorelease?
The point of my example was clarity, not speed. It can be confusing to
newbies to see a retain sent to an object, when it's not immediately
apparent that the target is the object that will eventually be
retained. It's a matter of semantics, I know - the retain is sent to
the same object, regardless of through which pointer the message is
sent. I think that sending the retain through the iVar pointer makes
it a bit clearer to newbies, though, why the object needs to be
retained.
If profiling showed the setter method to be a bottleneck, I'd compare
the pointers and avoid the autorelease/retain cycle entirely when
possible. A pointer comparison is cheap, and it remains clear at first
glance that the case where aString == clientCode is handled
differently.
The problem with that approach is that to spread out autorelease in
your code does not necessarily result in an easily identifiable
bottleneck. Most of the wasted time is spent in the autorelease pool
management and finding which accessors are responsible, if any, is
cumbersome.
Perhaps it's just my background showing. I've done a lot of Perl
programming over the past few years, and I've been burned far too many
times by idiomatic code that was slick, efficient, and a royal pain to
decipher. I've learned to favor clarity on the first pass, profile the
app, and then optimize away the clarity only where necessary.
The correct, fast, pattern can be written once and for all, for
instance in a macro. This results in both improved readability and
performance.
- (void) setClientCode:(NSString *) aString
{
ASSIGN (clientCode, aString);
}
This is how our ASSIGN macro is defined:
#if defined (GNUSTEP)
// GNUstep has its own definitions of ASSIGN and RETAIN
#else
#define RETAIN(var,val) \
do { \
id newVal = (val); \
if (var != newVal) { \
if (var) { \
[var release]; \
} \
if (newVal) { \
[newVal retain]; \
} \
var = newVal; \
} \
} while (0)
#if defined(GARBAGE_COLLECTION)
#define ASSIGN(var,val) \
do { \
var = val; \
} while (0)
#else
#define ASSIGN RETAIN
#endif
#endif
Marco Scheurer
Sen:te, Lausanne, Switzerland
http://www.sente.ch
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.