Date: Wed, 27 Nov 2013 04:10:35 +0000 From: Laurent Bercot <ska-dietlibc@...rnet.org> To: musl@...ts.openwall.com Subject: Re: [PATCH] Add support for leap seconds in zoneinfo files > By the way, this brings me to one part of the proposed patch that I'd > definitely like to see changed: the pre-parsing the leapseconds data > and storage in static memory. This both wastes static storage (800 > bytes for 64-bit systems) and puts an arbitrary limit on the data size > where it's not needed. I'd really prefer that the leapsecond > processing happen direct from the mmapped space, just like the way > time zone transitions are handled. Ok, but that will be more invasive. Time zone transitions can all be performed in __secs_to_zone, but leap second data needs to be available for __secs_to_tm and __tm_to_secs, since we only want to perform leap second calculations when converting from/to broken-down time, not when returning raw seconds: so interface changes will be necessary. > It would also be preferable to use > a binary search like what's used on the transition list instead of a > linear search; this change to binary search would probably more than > compensate for any performance loss from reading directly from the > mmapped data. I don't think it's needed. The leap second table is searched in descending order, and most calls to time functions are made with the current time, or something close to it, so a linear search will stop at the first item in most cases. And the rare worst case is only 25 iterations for now. I'll change to binary search if you insist, but I really feel it would add complexity for a very tiny benefit in the rare case and no performance increase at all in the common case. -- Laurent
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.