PHP Profiler to optimize & speed up your applications | Hacker News Reader

PHP Profiler to optimize & speed up your applications

github.com

56 pointsstutter20 comments

I have found Facebook's xhprof extension to be a a very useful extension for profiling also https://github.com/facebook/xhprof.

Unlike the one above, it doesn't require any code changes (it's a C-based PECL extension), and can easily be set up to be triggered via a parameter on the URL or to profile every nth page load (via a simple auto-prepend) for usage in production environments. It produces a full callgraph (using graphviz), you can drill down into the profile interactively, and you can record and compare profiles over time of the same page. It's also really quick and easy to setup and use.

There are of course other extensions that can do some profiling such as APD and XDebug, but xhprof is my personal favourite. I'm not sure I would ever be keen on confining my profiling to a PHP profiler written in PHP, although you do get some similar functionality from some frameworks such as debug mode in the Symfony framework.

There's also a GUI tool to go along with the backend work: http://phpadvent.org/2010/profiling-with-xhgui-by-paul-reinh...

Thank you, I had not seen your fork and modifications before. Will check them out!

Profiling PHP with PHP is kind of humorous, I'll concede. But it can certainly help alert you to slow-running pages, queries, and steps. Which should at least give you a starting point or prompt you to dive deeper with a stronger/more robust tool like xdebug+kcachegrind.

Thanks for checking out the library and providing feedback though, I appreciate it!

For more in depth profiling and optimization there is always APD: http://www.php.net/manual/en/book.apd.php

APD looks like it was abandoned in 2004.

Nice project but don't think I would use it in our enviroment for two reason:

1) It require code changes ... could be done when you're starting from scratch but nearly impossible for existing projects with really large code base. Moreover most PHP frameworks already provide similar functionality with deeper integration and better reporting.

2) This is the real dealbraker: having to add code manually means that eaither you go crazy and add profiling everywhere or it wont really help you because you'll add profiling only in the most obvious slowdown point and you'll discover what you already knew. But you'll probably loose hidden bottleneck in place you could not easily guess.

Both are valid points (editing code in order to profile), and you're absolutely right regarding blindly adding profiling wrappers "just because." You can certainly do that, but it's likely to be far too granular in a lot of places. The profiler attempts to hide the insignificant blocks so as to not make the output too noisy.

We use this profiler integrated into our in-house framework, so it's built-in to things like database access and action execution, with all the config/set-up separated. It took about 20 minutes to add the core set of blocks, not too bad; but I can definitely see and understand exactly where you're coming from.

thanks for the feeback

This requires instrumenting the code manually. For me this is a dealbreaker, because of amount of work required, overhead added and the fact that it won't report parts I don't instrument, so if anything unexpected is taking time, I won't notice.

I'll stick to XDebug + kcachegrind.

I also use XDebug + kcachegrind, but I wouldn't consider that a 'quick' way to identify slow-ups (mainly because of how my set-up looks).

I'll agree that manually creating steps around code you suspect to be an issue could be a pain in the rear, but it's not proven to be too terrible here.

Also, the profiler still shows you total execution time for the page regardless of adding profiling blocks. We also speak with our databases through a single class, so we can easily wrap query calls with the query profiling methods and identify slow queries.

Anyway, your points are completely valid. Thanks for looking it over and sharing your feedback in a constructive manner. It's nice to be able to leave my flame suit at home. heh.

I am with you on this one. I occasionally dip into codeigniters built in profiling as its useful for finding slow queries, but generally for anything other then SQL XDebug is a much better solution then mucking around wrapping code to profile it.

I know the obvious solutions for very low level profiling are xhprof and xdebug, but there is a time and a place for doing one off profiling. I can also recommend PHP Quick Profiler, released by Particle Tree a few years back, if you enjoy shiny things.

http://particletree.com/features/php-quick-profiler/

This bad boy has one added benefit over the others: console logging. Along the same token, you could be using a combination of Firefox with the FirePHP plugin if you like the idea of logging PHP directly to your firebug console:

http://www.firephp.org

Forgive me if this is a stupid question, but what's with the sleep functions between other function calls?

EDIT: Should have clarified. I'm referring to the demo.

I believe this is simply to test/show that it actually works.

That's just the demo, so you get some numbers in the output (since it doesn't do anything otherwise).

as the other two stated, the sleep calls just simulate actual code running, so the profiler produces some output other than 0ms for everything.

Class and demos starting with short php open tag (<?) and not working for me. Default php.ini file comes with 'short_open_tag = false'.

Though according to the manual short_open_tag is true by default, this is a valid point. The safer way to write this would have been to open all tags with <?php instead of <?. I'll update that.

thanks for the feedback!

Not according to the documentation and personal experience: http://www.php.net/manual/en/ini.core.php

thanks for this, excited to check it out

Reply on news.ycombinator.com