wtperf reports performance in operations per second. To measure the elapsed time for a test run, it counts the number of 1 second sleeps performed by the execute_workload() thread while waiting for the test to complete.

We should consider whether it would meaningfully increase accuracy to instead computer the elapsed run time for a test by reading the system clock at the beginning and end of the test and computing the difference.

The benefit of this approach would be improved accuracy. On modern systems the sleep() system call is typically very accurate – on a loaded Linux spawn host, I measure the time for sleep(1) to be no more than 100 microseconds (0.01%) over one second. But not all systems are as accurate. And this accuracy may degrade if the system is under extreme load – as might be experienced during a performance benchmark.

On the other hand wtperf has used this approach of counting one second sleeps for over 10 years (according to GitHub). Also, we often use wtperf not to provide highly accurate measures of a systems performance, but to compare performance between over time – for example in our performance regression tests. For these purposes consistency may be more important than accuracy down to the last percentage point.

If we choose to pursue this would should consider two non-technical points:

1. How will this affect performance regression tests. At a minimum, the corresponding PR should be flagged so any performance blips can be attributed to this change
2. Outside of our performance tests, is it important to be able to reliably compare performance across releases. If so, any change in how wtperf measures elapsed runtime should be backported to the appropriate older releases.