Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
- Subject: Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool
- From: j o a r <email@hidden>
- Date: Sat, 17 Nov 2007 12:46:58 -0800
On Nov 17, 2007, at 11:45 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...
Perhaps not fun, but probably pretty effective. As you don't have to
change your over all design patterns / architecture to make this
change I would also expect it to be fairly straight forward and safe.
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.
Unless you have a problem with the total amount of memory used per
iteration through the run loop I don't think that you should expect
that moving the pools around will make much of a 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.
How much memory do you use in total? How much installed in the
machine? Any paging / swapping (this is why I suggested including top
reports)?
<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>
They really do help, every single one of them. Radar is not a
replacement for the Developer Technical Support that Apple provides
and you shouldn't expect to use it as a communications channel with
Apple. You're side comment about "the hope it might be better in a
year" is spot on, and that's exactly what Radar provides: A way to
increase the chance that an upcoming Software Update, or major OS
release, will include a fix for the problem that you have reported. If
you don't file the Radar the likelihood that your problem will be
resolved is less than if you file the Radar. You will have to decide
for yourself if it's worth the time or not, but I would urge you make
the effort.
On Nov 17, 2007, at 12:38 PM, Gerd Knops wrote:
When testing on Leopard, I started my application through Xcode
(normal run, not debug). Apparently that slows it down a lot...
That is surprising, and worth additional investigation. Perhaps total
memory usage on the system is to blame after all?
[...] sadly under Leopard xcodebuild is no longer usable (50 sec
"checking dependencies") [...]
File a bug report! :-)
j o a r
_______________________________________________
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