[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20131127042550.GI24286@brightrain.aerifal.cx>
Date: Tue, 26 Nov 2013 23:25:50 -0500
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add support for leap seconds in zoneinfo files
On Wed, Nov 27, 2013 at 04:10:35AM +0000, Laurent Bercot wrote:
>
> >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.
__secs_to_tm and __tm_to_secs are not the right places for applying
leap seconds, because they affect gmtime, which is specified strictly
by POSIX to have a particular relationship with time_t...
> >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.
I'm faily indifferent on it, but I don't think the binary search is
significantly more complicated.
Rich
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.
