apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@ebuilt.com>
Subject Re: [PATCH] performance fix for time offset computation
Date Thu, 30 Aug 2001 20:56:13 GMT
On Wed, Aug 29, 2001 at 03:56:12PM -0700, Brian Pane wrote:
> I disagree.  Consider how the result of the calculation is used.
> We get the offset from the current time and then plug it into the
> time struct for a *completely different* time (in the explode_time
> function).  So the offset for computed by get_offset() for a machine
> in US/Eastern should always be -5 (really -5*3600).  If DST happens
> to be in effect, using -4 would be an error; there's no guarantee
> that the time to which we'll be applying the offset is on a date when
> DST is in effect.  The only safe thing to do is use the nominal
> offset for the location (-5 in this example) and then adjust it
> in the final apr_exploded_time_t if *that* time (not the current time)
> is on a date when DST applies.

Can we come to a conclusion on this?

In my tests, I see gmtime_r being a huge bottleneck.

At the very worst, have the timezone cached for 1 hour (or even better
build in to it knowledge when the timezone *may* change).  The cache 
check would be a lot cheaper than the call to gmtime_r (which on 
Solaris at least is a serialization point...).  -- justin


Mime
View raw message