[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
Delivered-to: email@hidden
Delivered-to: email@hidden

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:
http://lists.apple.com/mailman/options/cocoa-dev/email@hidden

This email sent to email@hidden

Prev by Date: Design Advice Sought for Interesting NSTableView
Next by Date: Re: Design Advice Sought for Interesting NSTableView
Previous by thread: Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
Next by thread: Safe asynchronous file copies
Index(es):
- Date
- Thread

Home