Timers and timing, was: MySQL Performance 6.0rc1

[Robert Watson]

On Sat, 29 Oct 2005, Poul-Henning Kamp wrote:

> The alternative is the degrade the quality of the standard timescales: 
> clock_gettime(CLOCK_REALTIME), time(2) and gettimeofday().
>
> The question there is: are we willing to live with the fallout ?

Another important question is whether using these alternative time access 
methods in user space improves the performance of any of the applications 
we care about.  Hence providing a patch that someone can try -- while the 
microbenchmarks seem to show improved performance, will the applications? 
I suspect it will in some important cases, but there's only one way to 
find out.

It strikes me that replacing time(3) with something that retrieves 
CLOCK_SECOND shouldn't harm time(3) semantics.  Likewise, keeping 
CLOCK_REALTIME as is is likely OK -- if an application requests it using 
clock_gettime(), then it is presumably looking for high accuracy.  It's 
gettimeofday() that's the troubling one -- it's widely used to query the 
time in applications, and its API suggests microsecond resolution.

Robert N M Watson