Re: encode-time vs decode-time

[Adam Porter]

Paul Eggert <address@hidden> writes:

Hi Paul,

> I looked briefly at it, and don't see any compatibility issues - not
> that I understand all the code, which depends on packages I don't use.

Thank you very much for looking at it.

> The code's comments say that format-time-string is too slow. What
> performance issues did you run into?

I didn't necessarily run into problems, but while doing some profiling,
I noticed that format-time-string was slower than I expected, so I tried
to implement some caching and avoid computing values unnecessarily.  You
can see some of my primitive test notes, e.g.:

https://github.com/alphapapa/ts.el/blob/master/notes.org#accessor-dispatch-vs-string-to-number-format-time-string

Some of those benchmarks may be out-of-date with respect to the current
code.

> At any rate I think you'll find
> that this:
>
>   (string-to-number (format-time-string "%Y" (ts-unix struct)))
>
> is more efficient written this way:
>
>   (nth 5 (decode-time (ts-unix struct)))

Thanks, I should have thought of that.

> and I expect you can speed up the code further by caching the entire
> result of decode-time instead of calling format-time-string for each
> component.

I do a form of that already in ts-fill by using format-time-string to
get all slot values and splitting the resulting string.  But that's a
good point, I might be able to use decode-time to improve it further.
I'll have to do some testing.  Thanks.

> Also, the timestamp functions in Emacs 27 should simplify ts.el, once
> you can assume Emacs 27. For example, in Emacs 27 you can do something
> like this:
>
>   (decoded-time-add X (make-decoded-time :year 10))
>
> to add 10 years to a broken-down timestamp X.

Thanks, I'll have to see if I can make use of those new functions.

> One more thing: ts.el's extensive use of float-time is fine for
> calendrical applications but has limited resolution (2**-22 s or about
> 2e-7 s for today's timestamps) and so would be problematic for apps
> requiring higher-resolution timestamps.

Right, thanks.  My use cases don't involve high-resolution timestamps,
so I decided to simplify things by only using Unix timestamp floats.
But there is a slot for internal time values, so if that were necessary,
the internal implementation could be changed to use them instead.

I'm curious, is Emacs fast enough or consistent enough to make use of
high-resolution timestamps anyway?  I guessed that, with GC pauses,
etc., it wouldn't be a suitable platform for such calculations in
real-time.  Although I guess if the timestamps were from outside Emacs,
one could operate on them anyway.

Grateful for your feedback!