

PHP Profiler to optimize & speed up your applications - stutter
https://github.com/jimrubenstein/php-profiler

======
morganpyne
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.

~~~
preinheimer
There's also a GUI tool to go along with the backend work:
[http://phpadvent.org/2010/profiling-with-xhgui-by-paul-
reinh...](http://phpadvent.org/2010/profiling-with-xhgui-by-paul-reinheimer)

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

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

~~~
powertower
APD looks like it was abandoned in 2004.

------
DivByZero
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.

~~~
stutter
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

------
pornel
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.

~~~
stutter
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.

------
jqueryin
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>

------
justindocanto
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.

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

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

~~~
stutter
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!

------
timpeterson
thanks for this, excited to check it out

