Posted by fabianx on February 18, 2012 at 6:14am
Hi High-Performance,
I am not sure how many of you tried to use XHProf on Mac OS X, but it was really unusable for me at times, because I would get rather random results due to Speed Stepping technology. Also the profiling time would never match the wait time shown in Chrome Network tab.
I made a patch to use the apple mach timer framework and I finally get accurate numbers each time now and they do also match the wait time shown both externally and internally (devel):
See https://bugs.php.net/bug.php?id=61132 for the patch and a little further explanation of the issue.
I just though this might be helpful for some of you using XHProf on Mac OS X :-).
Enjoy!
Best Wishes,
Fabian
Comments
This is great if you're
This is great if you're hosting your production sites on Mac OSX.
But if you are hosting on Linux, then doing XHProf performance tuning on Mac OSX isn't a good idea - the kernels are totally different, PHP will be probably be compiled differently, etc. The results you get from your analysis of your site on OSX will not match your production, therefore there's a chance of fixing the wrong thing.
XHProf should be installed on an actual production server to give relevant results, perhaps a web head that you remove temporarily from the pool for this purpose.
I've found that although
I've found that although XHProf numbers can't be directly compared Linux to Mac OS X, there is still plenty of value in seeing relative change within each system. I've never seen a case where an improvement in Mac OS X profiling yielding no improvement or a negative result.
Hi, I tend to disagree
Hi,
I tend to disagree here.
While performance analysis can easily be done online, actual performance improvements need to be done offline to be efficient.
I recently analyzed three sites and while my total numbers were of course off a little (even though not that much), the relative percentage always did hold and any improvement I did was reflected on the live sites as well.
Of couse PHP version plays a role.
On that regard, here are some nice relative numbers in regards to PHP version and one of the sites I analyzed:
PHP 5.2.10 -- 2s
PHP 5.2.17 -- 1.8s
PHP 5.3.6 -- 0.4s
Same DB, same original state, completely different run times.
Patching context and using blockcache_alter can again bring a lot of improvements (will share some other time).
That is also one big plus for Drupal 7 - that it is ready for PHP 5.3 out of the box and such can at times be much much faster than Drupal 6 even though it does much more.