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
> >that the QueryPerformanceCounter() can jump *ahead* a few seconds. I
> >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.
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?
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk