Re: Leopard performance penalty (3x slower), NSPopAutoreleasePool

FROM : j o a r
DATE : Sat Nov 17 21:46:58 2007

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