Subject: [boost] [chrono] steady_clock efficiency
From: Kenneth Porter (shiva.blacklist_at_[hidden])
Date: 2011-11-28 22:22:16
I expect most people will use boost::chrono::steady_clock to measure
performance. I've been considering switching from my raw calls to the
Windows peformance counter APIs to the steady_clock. I'm a little worried
about the overhead of what should be a non-intrusive facility.
In examing the source, I see that steady_clock::now() reads the performance
counter and then multiplies it by the reciprocal of the counter's frequency
(acquired on first use of the clock) to return the time in nanoseconds. How
expensive is this 64 bit multiply on a 32 bit system? How hard would it be
to have now() return a time_point that stores the raw tick value and only
converts it to nanoseconds when a calculation in real units is required?
(Comparison to another time_point could still be done in performance
counter ticks, saving the multiply.) Is it worth the extra complexity to
demand-convert ticks to nanoseconds?
Source is in boost_1_48_0\boost\chrono\detail\inlined\win\chrono.cpp
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk