Re: hi-res profiling

On 2 Oct 2002, at 12:09, Henrik Nordstrom <hno@marasystems.com> wrote:

> Andres Kroonmaa wrote:
> > On 2 Oct 2002, at 9:26, Henrik Nordstrom <hno@marasystems.com> wrote:
> > > > Can probes reenter?
> > >
> > > From reading the source it seems nesting is not supported very well
> > > within the same performance counter. If you do the readings will be
> > > somewhat screwed up usually giving more time spent in the counter
> > > than actual, counting the time from last start to each stop.
> >
> > you mean opposite, it shows less time than actual. Time between
> > successive starts is lost.
>
> While that is true, it also counts the time twice for each stop.
>
> The time between consequtive START is lost.
>
> The time between the last START and all STOP is counted twice, once per STOP.

 Yes, which leads to error that accounted time is either equal or less
 than actual. In recursive case there is no other possibility, is it?
 Each successive STOP should count more time than previous STOP, from
 its peering START, but counts only from last START.
  (((((..))))) -> (..)))))
 It has to count time for each STOP anyway, for each invocation of func.

 Got to think that we could even account for that if we assume that
 time to run recursion is about the same, then we can store 2 stamps
 for Start, one for first invocation, and other for any successive.
 Then, at Stop time, if both Start stamps are filled, calc START stamp
 that fits between the two: ((:{(..))))) -> ( ..)))))
 We'd get averages right, but all else still wrong. But I still think
 that fiddling with recursion is not needed, we get better info if we
 avoid it knowingly altogether.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 CTO, Microlink Online
 Tel: 6501 731, Fax: 6501 725
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Wed Oct 02 2002 - 04:33:23 MDT