Re: [boost] Re: Re: Re: Re: Profiling Library suggestion

From: christopher diggins (cdiggins_at_[hidden])
Date: 2005-02-19 09:45:44

----- Original Message ----- 
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>; <boost_at_[hidden]>
Sent: Friday, February 18, 2005 5:00 PM
Subject: Re: [boost] Re: Re: Re: Re: Profiling Library suggestion

> At 07:30 PM 2/13/2005, christopher diggins wrote:
> >> iteration.
> >
> >Really? That is different than the issue documentation I found at
> >http://support.microsoft.com/default.aspx?scid=kb;EN-US;q274323 which
> stats
> >that the QueryPerformanceCounter() can jump *ahead* a few seconds. I
> wonder
> >if the status of the issue has changed to this new version or the
> >documentation just sux.
>
> There is another problem with QueryPerformanceCounter(); the latency (time
> spent executing the call itself) varies dramatically depending on (1) the
> version on Windows, and (2) which compiler was used. Why the compiler
> should have a strong effect on the latency of an API call is a mystery.
>
> John Maddock and I ran some tests several years ago, and both of us could
> reproduce the effects. I recently downloaded some timing code written by
> someone else, tried it with several compilers and the effect still appears
> to exist with current compilers. So be careful, and be sure to test with
> different versions of Windows and different compilers.
>
> --Beman

Thanks for the advice Beman. I would like to submit the profiler library to 
boost *without* a high-resolution timer, and rather only provide the 
guarantee of satsifactory performance when used with boost::timer. I am 
using a policy driven design and the user can supply an arbitrary timer 
class which models boost::timer. I see timers as a separate problem from the 
profiler, that I don't want to get into. What do you think, would this kill 
the chances of a profiler ever becoming part of boost?

best,
Christopher