[xdebug-general] Re: how would you find performance loss?

On 4 Jan 2007, at 15:31, Prometheus Prometheus wrote:

> one of my problems is: what does cumulative mean? or: what is
> cumulated? and what means self vs. cumulated?
> i mean if a function is called 10 times within 1 request and the
> function takes 1 second per call, what does cumulated and self
> mean? or how are these values affected? (by only 1 request or by
> many?)

self contains the time that the function itself consumes. Cumulative
time includes the time taken by functions that it calls. So if you
had a function that does nothing but loop calling some other
function, you would expect self to be low, and cumulative to be high.
You will also see a call count next to the function that is called.

> i'm using wincachegrind to view the data i'm not sure if i
> interpret it correctly

If you can, use kCachegrind as it's much more complete and interactive.

> but the main question would be how would you find a performance
> problem?
> what indicates a problem and what not?

Only you can know that - spot functions that are being called too
often, functions that are taking longer than expected. Functions that
have the largest self values are usually the bottlenecks.

> in my application, the php script waits within a loop for request's
> and this function which waits takes 90% which makes sense, since it
> runs a long time, but only a few milliseconds the script does
> something different than "waiting" for the next request
> which means the "wait for next request" function affects or tampers
> the performance data
> but how do i find the real performance problem?

It's easy enough to ignore a function that is occupying idle time -
you're only interested in what happens when it gets busy.
kCacheGrind's graphing makes this much easier to visualise.

> btw: if i do 10 requests, which one is saved in the cachegrind
> file? an average over all 10 requests? or the last one?

That's configurable in the xdebug php.ini settings. For web hits, you
usually you want to just profile the single most recent hit, but when
profiling a daemon or other looping app, you'll probably want to let
it accumulate multiple iterations, where averages become more
interesting than individual stats.

I have a problem in a daemon that's hard to diagnose right now - I
have a function that creeps up in duration from about 0.02ms to about
0.5ms over the course of several thousand iterations. It's proving
very hard to nail down.

Marcus

-- 
Marcus Bointon
marcus@bointon.com | http://marcus.bointon.com/