apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Holsman <i...@cnet.com>
Subject Re: [PATCH] performance fix for time offset computation
Date Thu, 30 Aug 2001 21:35:16 GMT
Justin Erenkrantz wrote:

> 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
> 

+1 on the patch. (sick of seeing 9 time calls for every mod-include request)


Mime
View raw message