Re: Question about bignum usage

["Mattias Engdegård" <mattias.engdegard@gmail.com>]

11 juli 2024 kl. 16.10 skrev Paul Eggert <eggert@cs.ucla.edu>:

> I installed the attached. 0017 should should address the performance problem with decode_timer. The other patches refactor and address some related issues.

That was a lot more ambitious than I had in mind, thank you!

I pushed a tiny simplification. More can be done. For example, time decoding output sometimes depends on the exact form of the input:

(time-convert '(0 3) t) => (3 . 1)
(time-convert '(0 3 0) t) => (3000000 . 1000000)
(time-convert '(0 3 0 0) t) => (3000000000000 . 1000000000000)

Does it make sense to distinguish (A B), (A B 0) and (A B 0 0) like this? Some kind of performance hack to keep denominators the same?

> As I understand it decode_timer was the locus of the performance issue. If other places are also involved, please let me know.

It probably dealt with the most noticeable parts but the timer system doesn't appear to be short on slow code.
For example, does timer_check really need to duplicate the time queues each time they are checked for an event to run, even if there isn't one?
Not to mention the baroque time representation of `timer` objects and the cost of time-less-p and (especially) timer--time-less-p.

Can we make changes to the `timer` struct now? Apparently there were some holdouts in 2012 (which is why the `psec` slot is where it is) but there has to be a limit to how we have to support old badly written code.