[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
