On 8/14/22 10:15, Stefan Monnier wrote:
> E.g. if we do (time-convert FLOAT t)
> the returned value will be of the form (TICKS . 2^51) and for
> (time-convert (HI LOW US) t) it'll be (TICKS . 10^6), but
> `lisp_to_timespec` doesn't seem to have a fast path for 2^51 and I'm not
> sure it has one for 10^6 (nor 10^12 used for (HI LOW US PS)).

I hadn't written fast paths for those, no.

The idea is that (time-convert X t) should be best if you want full 
precision. If you want only one-second precision, (time-convert X 
'integer) should yield timestamps that are a bit faster, because there's 
no need for consing.

I just now looked at the code and found a couple of places where integer 
timestamps were significantly slower, and wrote and installed the 
attached performance tweaks to fix that.


> - There doesn't seem to be an easy way to get `timespec_hz` from ELisp.

Why would code need timespec_hz, if (time-convert X t) suffices for 
conversion to full precision?

Code that needs timespec_hz can get it with (cdr (time-convert nil t)). 
If that's too cumbersome we could add a builtin integer for it, though 
there's a caveat here: some timestamps can use a different hz value than 
others, so the builtin integer would be only for the timestamps 
retrieved from (time-convert ... t) and not necessarily for other (TICKS 
. HZ) timestamps retrieved from the system via file-attributes etc. To 
avoid this confusion it might be better not to have that builtin integer.


> - It's cumbersome to find out if a time value is a whole number
>    of seconds.

If (time-equal-p X (time-convert X 'integer)) is too cumbersome, we 
could add a function to do that.


> Of course, maybe we shouldn't care, and just presume that the slow path
> which does a GMP mul+div is plenty fast anyway.

Yes, the goal is that this stuff "just works" without people having to 
worry overmuch about speed.