Re: Newbie with stupid question cont.
Re: Newbie with stupid question cont.
- Subject: Re: Newbie with stupid question cont.
- From: email@hidden
- Date: Tue, 19 Mar 2002 12:09:53 -0800
for(x=0 ; x < [ifaces count]; x++){
sReturn = [NSString stringWithFormat:@"%@ (%@)", [ifaces
objectAtIndex:x], [self getIPForInterface:[ifaces objectAtIndex:x]]];
[arrReturn addObject:sReturn];
[sReturn release]
}
And you probably don't want to have a bunch of autoreleased objects
in a
loop. The autorelease pool will get really big and slow down your app.
If
performance is an issue, then you should avoid autoreleased objects
being
created inside of loops which count potentially happen a bunch of
times.
Nope. quite the contrary. With a vast majority of loops (depends on
other
conditions too, but a rough guess might be up to XXX iterations)
autoreleasing makes no problem at all, and the slowing down is
unnoticeable.
If the loop is to be iterated many times indeed, the solution is still
autoreleasing, this time with a local loop:
for (...many times...) {
NSAutoreleasePool *pool=[[NSAutoreleasePool alloc] init];
...
[pool release];
}
I am going to have to disagree *quite* emphatically with Ondra here.
If we're talking about 10 or even 100 iterations, it doesn't matter
much. But if you're looping much more than that, using autorelease will
make for a *big* speed difference in your loop's total execution time.
Depending upon whether you use an NSAutoreleasePool in the loop to cause
immediate releases, the overhead may occur in the loop itself, or it may
occur down the road when the top-level autorelease pool pops (so anybody
trying to write code to time this, be careful to measure the full
overhead of the autoreleasing :->). But you *will* get that overhead,
and for loops which aren't doing a heck of a lot else, it *will* be by
far the most costly thing your loop does. (In the example above, my
guess is that +stringWithFormat:, which is an extremely slow method,
would give autorelease a run for its money, but many loops don't have
anything as slow as +stringWithFormat: in them).
This kind of devil-may-care coding is a lot of what made 10.0 so
slow. And in the big optimization push for 10.1, getting rid of
unnecessary autoreleasing was one of the biggest (and easiest) wins
available, and made a truly huge difference in some code bases (like the
one I was working on). We're talking reductions in time for some
operations of as much as an order of magnitude.
Again, to emphasize: 10 or even 100 autoreleased objects won't make a
whit of a difference. Autorelease is a convenience, and a very valuable
one. Don't go off half-cocked trying to eliminate every autorelease in
your code, it will just make your code harder to read and maintain, and
will probably introduce retain/release bugs. But when dealing with a
lot of objects (i.e. looping a lot of times), autorelease can contribute
a truly staggering amount of overhead to your code, and eliminating it
can be key to achieving good performance.
Ben Haller
Stick Software
_______________________________________________
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.