Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
- Subject: Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
- From: Gerd Knops <email@hidden>
- Date: Sat, 17 Nov 2007 13:45:34 -0600
On Nov 17, 2007, at 1:12 PM, j o a r wrote:
On Nov 17, 2007, at 10:53 AM, Gerd Knops wrote:
I have a complex Cocoa application, 10.4 SDK (no GC etc). Loading a
document (and performing a large number of calculations triggered
by that) takes 4 seconds under Tiger.
Under Leopard, loading the same document takes 8 seconds until it
displays, after which the application is unresponsive for another 4
seconds, the entire time being spent in NSPopAutoreleasePool.
I presume that performance penalty is largely due to Leopards more
complex memory handling. Has anybody else observed this, and knows
of any strategies to minimize that overhead?
What "more complex memory handling" are you referring to? Do you
compare loading the document between Tiger and Leopard on the same
machine (same hardware and amount of RAM)?
Yes, at least initially. Now to speed things up I am using a (actually
slower, but same setup, memory etc) machine to run Tiger, the results
are the same as when I run on the same machine.
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.
You may also want to file a performance regression bug report with
Apple. I would suggest including: Shark Time Profile, Shark Time
Profile (All Thread States), System Profile, top output. Make sure
to sample the whole duration of loading the document, and include
reports from both Tiger and Leopard.
I doubt that is going to be helpfull, as Shark records the time spent
in NSPopAutoreleasePool as being in main(), and nothing else really
jumps out, the slowness is all across the board.
<rant>Also do radars ever actually help? I have spent many hours
filing detailed radars, and best case (if I get an answer at all) a
year or so later I hear "we can no longer reproduce this in our
upcoming release". Somewhat frustrating, I'd rather spend the time
playing with the dogs... For all the time I invested, I have never
ever got a single helpful line back (like do x and things will be
better). Makes me feel like I am spending my time (and money) to help
Apple debug their stuff, for zero (other than the hope it might be
better in a year) return. So basically the ROI on radars is extremely
poor, and I can't make a business case for them. You may call that
anti-social, but not working for a large company these radars do cost
me actual dollars. Sorry for the rant...</rant>
Gerd
_______________________________________________
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