emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to canonicalize a time object


From: Paul Eggert
Subject: Re: How to canonicalize a time object
Date: Sun, 14 Aug 2022 14:17:29 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0

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.

Attachment: 0001-Decode-time-conses-before-floats.patch
Description: Text Data

Attachment: 0002-Improve-timefns-speed-on-integers.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]