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.
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!
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.
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 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.
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:
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.
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.