Boost logo

Boost :

From: Gennadiy E. Rozental (rogeeff_at_[hidden])
Date: 2001-10-31 17:16:57


Hi,

I was thinking about implementing timing functions or reusing some
other implementation while working on Performance testing tools for
Boost Test library. If you find any appropriate solution I would like
to hear about it.

Gennadiy.

--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> At 10:54 AM 10/31/2001, Toon Knapen wrote:
>
> >I need to be able to toggle the timer on and off. Since I want to
> >calculate the total time spend in some function I need to toggle
the
> >timer off everytime the program leaves the function and back on
> >everytime the program enters the function again.
> >So I propose to add a member called `toggle()`.
> >A drawback though is that you need to `toggle` the timer back on
before
> >asking the `elapsed()` time (otherwise I would need a bit to
indicate if
> >the timer is on or off which increases the memory footprint.
Maybe I
> >could use the MSB of the clock_t as a hack)
>
> I sympathize with the need to measure total time in a function, but
I
> wonder if toggle() is the way to do it.
>
> Problems I see:
>
> 1) User needs to remember to toggle() the time off initially so
that the
> sequence of toggles is correct, and then toggle() it back on before
the
> call to elapsed().
>
> 2) On many systems, either the timer precision is so low or the
time
> latency is so high that it is impossible to use to measure the time
spent
> in a single function invocation, unless the function is a major
time
> burner. The only reliable way is to invoke the function a very
large
> number of times, and then divide the elapsed time by the number of
> invocations. This problem isn't unique to boost::timer, and is
probably
> getting much worse a clock speeds increase. How many modern
platforms can
> actually deliver timings with high enough precision and low enough
latency
> to accurately measure a single invocation of a smallish function?
>
> I'm inclined to think the solution may not be to try to fix timer,
but
> to specify a new timing library with much more precise semantics.
>
> If Jeff Garland is reading this, I'd be curious if his date and
time
> classes would solve the problem. I know they can handle very large
> granularity (100 year, for example, used in measuring geological
time), but
> I don't remember if they can handle very small time periods, and
what they
> do if the hardware timers can't deliver the precision desired.
>
> >In attachment you can find my proposal implementation (Oh, I also
> >aligned with the coding guidelines AFAIK : trailing underscore for
> >members, ... )
>
> Always hard to tell exactly what changed when the formatting is
also
> changed. I'm assuming the toggle() code was the only substantive
change.
>
> Thanks,
>
> --Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk