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

[boyter]

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.