Happened to note that linux implements the posix clock_gettime(3)
interface, so I fixed 7.7 to use that for gethrtime and gethrvtime.
And lo and behold, it now has nice nanosecond resolution with thread
local accounting for cpu time. :) (At least with a fairly modern
linux - ymmv.)
For those that don't know, this has been miserable before. The best
function supported by glibc has been times(2) which has lousy
resolution (10 ms!) and isn't thread local. That has rendered
gethrvtime and gauge practically useless.
So I was thinking of adding a nanosecond variety of gauge {...} too.
It's not strictly necessary; the current gauge in a pike compiled with
standard 32 bit floats can just barely cope with the time for the
shortest possible pike snippet:
> sprintf ("%e %.9f", gauge {}, 1 + gauge {});
Result: "7.210e-07 1.000000715"
A gauge that returns integer nanoseconds could however be useful if
one adds together a lot of short intervals, and it's very easy to add.
In lack of better ideas, I was thinking of calling it "hr_gauge". What
do you think? Note that the name would become a new keyword.
|
