On 24/9/22 04:51, Paul Eggert wrote:
On 9/23/22 04:19, Ted Phelps via tz wrote:
https://github.com/tphelps/tz64/
The performance improvement is substantial; on my laptop (Intel i7-8550U, 4GHz) it takes about 35ns to convert a struct tm to a time_t; whereas mktime_z takes about 3,300ns.
Which, finally, brings me to my question: is there any interest in reworking tzcode's mktime to use a more efficient algorithm?
Sure, if it's easy. Would you be willing to contribute code under the current license for mktime? It's public domain. We could add your name to the credits, if that would help.
I'll try to make it easy. Yes, I have no problem contributing under the current license. One important trick I've used is to embed a year/month/day/hour/minute value in a 64 bit integer for each leap second. That would work out to 8 x TZ_MAX_LEAPS = 400 extra bytes in struct state. Is that likely to be a problem?
Although I don't want tzcode to assume 64-bit signed time_t, I assume it wouldn't be hard to relax that assumption.
Agreed. It's easy to do the math in 64 bits and then return an error if the result doesn't fit into 32. It's rather harder to do the math in 32 bits since there are so many opportunities to overflow, but I see that there's already an int_fast64_t type in localtime.c so I guess 64-bit math is acceptable? -Ted