11–20 of 24 posts
I'll stick to XDebug + kcachegrind.
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.
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.
Class and demos starting with short php open tag (<?) and not working for me. Default php.ini file comes with 'short_open_tag = false'.
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:
Class and demos starting with short php open tag (<?) and not working for me. Default php.ini file comes with 'short_open_tag = false'.
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.
Class and demos starting with short php open tag (<?) and not working for me. Default php.ini file comes with 'short_open_tag = false'.
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 eaithe…
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'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.