Re: boost.timer

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