[tz] Direct implementation of mktime_z
Ted Phelps
phelps at pobox.com
Sat Sep 24 05:29:29 UTC 2022
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
More information about the tz
mailing list