Kenneth Porter-2 wrote
"Vicente J. Botet Escriba" <vicente.botet@> wrote in news:4ED49A27.2030500@:
Glad to hear you are considering it. Have you any measures that let you think there is a serious overhead? How do you use the ::now() function to make your performance measures?
Thanks for the feedback. A typical use case:
const time_point startTime = steady_clock::now(); // stuff to measure here const time_point endTime = steady_clock::now(); const duration elapsed = endTime - startTime;
Ideally the conversion from ticks to nanoseconds would be done by the subtraction operator.
We could see a little improvement in this case as the conversion could be done only once, instead of two. Note the rt_ prefixes in the code (for run-time): const rt_time_point startTime = rt_steady_clock::now(); // stuff to measure here const rt_time_point endTime = rt_steady_clock::now(); const duration elapsed = duration_cast<duration>(endTime - startTime); // conversion is done by the cast operator The conversion from rt_duration to duration could also be implicit and the last line be const duration elapsed = endTime - startTime; // conversion is done implicitly by a implicit conversion operator Another use case, waiting a precise amount of time: void wait(const duration timeToWait) { const time_point endTime = steady_clock::now() + timeToWait; while (steady_clock::now() < endTime) ; } Here, the conversion from nanoseconds to ticks would be done by the addition operator, so that the time_point comparison would be in ticks. More exactly it should be done on the conversion from the timeToWait to ticks to wait void wait(const rt_duration ticksToWait) { const rt_time_point endTime = rt_steady_clock::now() + ticksToWait; // ** ticks while (rt_steady_clock::now() < endTime) ; } void wait(const duration timeToWait) { wait(rt_duration_cast<rt_duration>(timeToWait); // conversion to ticks } Again if the conversion from duration to rt_duration is implicit the last line becomes wait(timeToWait); and so the wait specialization will be not really needed. I'd use this where I need to wait a small amount of time (much less than a scheduler tick) for a hardware device to respond, before giving up my time slice. I understand the use case. I don't see a major difference in this case as what is important is the accuracy, which IMO is preserved. With the current design/implementation your processor will be just more busy which is no good however. I will add some performance tests that measure the the time spent to get the ticks and the period, to see if it is worth continuing. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/chrono-steady-clock-efficiency-tp4117923p... Sent from the Boost - Dev mailing list archive at Nabble.com.