Re: sending release to nil
Re: sending release to nil
- Subject: Re: sending release to nil
- From: Jeff Disher <email@hidden>
- Date: Thu, 16 Jan 2003 00:38:31 -0500
Well, I built a simple test case that simply ran the operation
1,000,000,000 (1 billion) times.
No optimization.
On my iBook 600:
C++: deleting null 1 billion times:
user 0m23.890s
Obj-C: releasing nil 1 billion times:
user 0m52.750s
Obj-C: releasing nil 1 billion times if not nil (essentially just
running the if statement 1 billion times):
user 0m17.060s
So, you see that you will always be fastest with checking the if
(although I think it should have been faster since that means that I
was averaging 10 cycles per iteration to simply branch - but that is
without optimization, so it makes sense). This seems to be the logical
answer, as well.
Bear in mind that it is highly unlikely that this will be the expensive
operation in a program. I know that when I write this sort of
situation, I just release it and set it to nil without bothering to
check what the value is. It is significantly faster, but sending the
release call is probably the least costly operation out of all of the
things I would ever do in a program.
Hope that answers your question,
Jeff.
On Wednesday, January 15, 2003, at 11:29 PM, Ted Lowery wrote:
Hi all-
As an ex-C++ programmer (I say 'ex' because I am completely sold on
the ease of development and features of objective-C, now if I can only
find a paying job...), I am used to the limitation of not being able
to free an object more than once. Early on, my code was littered > with:
if (obj) delete obj;
obj = NULL;
Then, as I learned, I created a free pattern (idea courtesy of Mike
and Phani):
#define kill(x) if (x) delete x; x = NULL;
then I could free an object as much as I wanted.
Anyhow, now that I am discovering the power of objective-C, I notice I
can send nil a release message, and it really doesn't care. So my
current pattern is:
if (obj) [obj release];
obj = nil;
but I can also drop the if part, and code works fine.
My question is (I know, you were wondering if I would ever get to it?):
There is a performance hit for using if, and I assume there is a
performance hit for sending release to nil. I would surmise the if is
faster than messaging all the way to nil, though obj-C may do
something cool for me that mitigates. Of course, I could be dead
wrong as well.
I'm too lazy to build a test case, so I thought I'd pose to this group.
Hang on, the question is coming, I promise...
What patterns do you use?
if?
multiple releases to nil?
does it make a measurable difference if I bracket the release and nil
assignments?
something else I'm not thinking of?
Thanks for the help, everyone.
Cheers, Ted
_______________________________________________
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.
Jeff Disher
President and Lead Developer of Spectral Class
Spectral Class: Shedding Light on Innovation
http://www.spectralclass.com/
_______________________________________________
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.