----- Original Message ----- From: "Beman Dawes" <bdawes@acm.org> To: <boost@lists.boost.org>; <boost@lists.boost.org> 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