Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
- Subject: Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
- From: Ben Trumbull <email@hidden>
- Date: Sun, 18 Nov 2007 21:45:03 -0500
On Nov 17, 2007, at 10:53 AM, Gerd Knops wrote:
You should probably investigate trying to create fewer temporary
objects, and fewer autoreleased objects, as a way to fix this
problem on your end.
That would be a less than fun task, given >50.000 lines of code...
I did sprinkle a number of local NSAutoReleasePools, so that
autoreleased objects do not amass. That made no (measurable)
difference in performance at all. I no longer have the 4 second period
of unresponsiveness, but the overall process takes 4 seconds longer,
so that was a wash. By adding timestamps before and after the
[autoReleasePool release] I can see that they now roughly share the
burden (eg take about the same time). So having all the temporary
objects in one large pool or a number of smaller pools makes no
difference.
If Shark is reporting a lot of time popping an autorelease pool, then
using fewer temporary/autoreleased objects is obvious.
-autorelease is a convenience. It's handy, saves a couple lines of
code, can provide a simpler API, and can eliminate extra code in
places you expect exceptions to be thrown.
It's also, relative to just -release, expensive. In addition to all
the extra work to keep track of the object until the pool is released,
it requires more memory. The memory for a temporary object can't be
reused for something else until you actually release it. So an
autorelease pool extends the lifetime of those objects. Sometimes
that's a useful feature. It can make an API less error prone.
Sometimes it's just a performance drain. Unnecessarily extending the
lifetime of memory blocks means that the process needs more memory.
It needs to compensate for all the temporary blocks that are pending
in the autorelease pool, but never used again. Growing the high
watermark of a process heap means that more memory needs to be
allocated from the OS. That is much much much more expensive than -
release.
So using autoreleased objects within performance critical loops is
very counterproductive.
It also sounds like you're allocating a large number of objects. You
may be able to improve performance by allocating fewer objects
overall. This is more work than simply releasing temporary objects
more aggressively, but can provide additional improvements. Depending
on what you need, you can reuse allocated objects (allocate a mutable
object, and mutate instead), malloc a large buffer and divide it up
yourself, or use the batch malloc APIs in malloc.h
- Ben
_______________________________________________
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