You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Brian Pane <bp...@pacbell.net> on 2001/08/28 12:26:42 UTC
[PATCH] performance fix for time offset computation
On platforms where neither HAVE_GMTOFF nor HAVE___OFFSET is defined,
like Solaris, the function "get_offset" in apr/time/unix/time.c is a
bottleneck in time formatting.
On these platforms, get_offset ignores its argument; it really computes
the server's offset from GMT, normalized so that it's independent of
daylight savings.
The following patch caches the offset after it's first computed, so
that we don't have to compute it repeatedly.
--Brian
Index: apr/time/unix/time.c
===================================================================
RCS file: /home/cvspublic/apr/time/unix/time.c,v
retrieving revision 1.51
diff -r1.51 time.c
88,89c88,92
< {
< time_t t1 = time(0), t2 = 0;
---
> static apr_int32_t cached_offset = 100;
>
> if (cached_offset == 100) {
> struct timeval now;
> time_t t1, t2;
92a96,99
> gettimeofday(&now, NULL);
> t1 = now.tv_sec;
> t2 = 0;
>
101c108
< return (apr_int32_t) difftime(t1, t2) + (was_dst ? 3600 : 0);
---
> cached_offset = (apr_int32_t) difftime(t1, t2) + (was_dst ?
3600 : 0);
102a110
> return cached_offset;
Re: [PATCH] performance fix for time offset computation
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 28 August 2001 10:28, Brian Pane wrote:
> >>Would anybody besides me feel better if we had apr_initialize() call
> >>apr_unix_setup_time() to do this?
> >
> >Apparently :) +1
>
> What's the right way to introduce a declaration for apr_unix_setup_time
> (or should it be apr_setup time in case we later need a similar trick on
> other platforms?)...wrap it in an ifdef in apr/include/apr_time.h, or
> add a "time.h" (er, but probably not called "time.h") in the
> apr/include/arch/* directories?
Just do exactly what we did for apr_unix_setup_lock. Namely, create an
apr/include/arch/unix/internal_time.h and declare it there.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PATCH] performance fix for time offset computation
Posted by Brian Pane <bp...@pacbell.net>.
William A. Rowe, Jr. wrote:
>From: "Jeff Trawick" <tr...@attglobal.net>
>Sent: Tuesday, August 28, 2001 6:47 AM
>
[...]
>>Would anybody besides me feel better if we had apr_initialize() call
>>apr_unix_setup_time() to do this?
>>
>
>Apparently :) +1
>
What's the right way to introduce a declaration for apr_unix_setup_time
(or should it be apr_setup time in case we later need a similar trick on
other platforms?)...wrap it in an ifdef in apr/include/apr_time.h, or
add a "time.h" (er, but probably not called "time.h") in the
apr/include/arch/* directories?
Thanks,
--Brian
Re: [PATCH] performance fix for time offset computation
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
From: "Jeff Trawick" <tr...@attglobal.net>
Sent: Tuesday, August 28, 2001 6:47 AM
> Brian Pane <bp...@pacbell.net> writes:
>
> > On platforms where neither HAVE_GMTOFF nor HAVE___OFFSET is defined,
> > like Solaris, the function "get_offset" in apr/time/unix/time.c is a
> > bottleneck in time formatting.
> >
> > On these platforms, get_offset ignores its argument; it really computes
> > the server's offset from GMT, normalized so that it's independent of
> > daylight savings.
> >
> > The following patch caches the offset after it's first computed, so
> > that we don't have to compute it repeatedly.
>
> Would anybody besides me feel better if we had apr_initialize() call
> apr_unix_setup_time() to do this?
Apparently :) +1
Re: [PATCH] performance fix for time offset computation
Posted by Ryan Bloom <rb...@covalent.net>.
On Tuesday 28 August 2001 12:32, Greg Stein wrote:
> On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> > Here's a new version of the get_offset patch that initializes
> > the TZ offset from apr_initialize. I've attached the new include
> > file that it uses, apr/include/arch/unix/internal_time.h
>
> I don't like Ryan's suggestion for a whole new header just to prototype a
> single function. Lets used arch/unix/misc.h for this instead.
I don't like putting things in the wrong place. The whole misc thing was one
of my biggest mistakes with APR. If we can't label what the feature is doing,
we shouldn't do it.
This really belongs in a separate time.h header file.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
Re: [PATCH] performance fix for time offset computation
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> Here's a new version of the get_offset patch that initializes
> the TZ offset from apr_initialize. I've attached the new include
> file that it uses, apr/include/arch/unix/internal_time.h
+1. This function call has been a thorn in my side for a while. =)
Thanks. I'll commit later today if no one beats me to it. -- justin
Re: [PATCH] performance fix for time offset computation
Posted by Justin Erenkrantz <je...@ebuilt.com>.
On Thu, Aug 30, 2001 at 04:19:20PM -0700, Brian Pane wrote:
> Here's a revised copy of the patch--same code, but with comments added.
> It depends on the new include file apr/include/arch/unix/internal_time.h.
> --Brian
Committed. Thanks. -- justin
Re: [PATCH] performance fix for time offset computation
Posted by Brian Pane <bp...@pacbell.net>.
Roy T. Fielding wrote:
>On Thu, Aug 30, 2001 at 01:56:13PM -0700, 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?
>>
>
>I am still +1 on the patch -- I just want someone who understands what
>the heck it is doing to add documentation, like they are SUPPOSED to do,
>so that I don't have to ask annoying questions about its behavior.
>[Or at least so that its easy to tell me to go RTFM.] Right now it
>is relying on a side-effect of the proceesing of an OS-dependent data
>structure to obtain some performance benefit, which is a fine idea if
>it is properly documented as such.
>
Sounds reasonable to me. I'll repost the patch in a minute with
some added comments documenting why it computes and caches a DST-unaware
offset.
--Brian
[PATCH] performance fix for time offset computation
Posted by Brian Pane <bp...@pacbell.net>.
Here's a revised copy of the patch--same code, but with comments added.
It depends on the new include file apr/include/arch/unix/internal_time.h.
--Brian
Re: [PATCH] performance fix for time offset computation
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Thu, Aug 30, 2001 at 01:56:13PM -0700, 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?
I am still +1 on the patch -- I just want someone who understands what
the heck it is doing to add documentation, like they are SUPPOSED to do,
so that I don't have to ask annoying questions about its behavior.
[Or at least so that its easy to tell me to go RTFM.] Right now it
is relying on a side-effect of the proceesing of an OS-dependent data
structure to obtain some performance benefit, which is a fine idea if
it is properly documented as such.
....Roy
Re: [PATCH] performance fix for time offset computation
Posted by Ian Holsman <ia...@cnet.com>.
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)
Re: [PATCH] performance fix for time offset computation
Posted by Justin Erenkrantz <je...@ebuilt.com>.
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
Re: [PATCH] performance fix for time offset computation
Posted by Brian Pane <bp...@pacbell.net>.
Roy T. Fielding wrote:
>On Wed, Aug 29, 2001 at 10:19:40AM -0400, Greg Marr wrote:
>
>>At 10:05 AM 08/29/2001, William A Rowe wrote:
>>
>>>>At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
>>>>
>>>>>On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
>>>>>
>>>>>>As far as I can tell, the result of the calculation should be
>>>>>>independent of daylight savings (e.g., always 5 for
>>>>>>
>>>US/Eastern).
>>>
>>>>>Then the calculation must be wrong, since EDT is -0400. EST is
>>>>>
>>>-0500.
>>>
>>>>How is the calculation wrong? It should be 5, it is 5, I don't
>>>>
>>>see
>>>
>>>>the problem.
>>>>
>>>Only if you collect DT as +0100 in a seperate operation, and use the
>>>net result (-0400) when computing between LT and ST.
>>>
>>I wasn't referring to the usage of the value, I was referring to the
>>calculation itself. Brian said it was independent of DST, and
>>produced 5 for US/Eastern. Roy said the calculation must be wrong
>>since EDT is -0400, which makes no sense.
>>
>
>Well, at this point, I don't understand what the heck you guys are talking
>about. The patch introduced a cache for the gmtoffset which, just as it
>is named, represents the time difference from GMT/UTC to local time. Right?
>
Right.
>For a system located in Maryland, USA, the gmtoffset is negative four hours
>during daylight time and negative five hours during standard time, so if
>you store a cached value of the offset then the value is going to be
>four or five. If the calculation always results in five, then obviously
>something is wrong. Either the calculation is wrong or what it is
>calculating is not the gmtoffset.
>
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.
--Brian
Re: [PATCH] performance fix for time offset computation
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Wed, Aug 29, 2001 at 10:19:40AM -0400, Greg Marr wrote:
> At 10:05 AM 08/29/2001, William A Rowe wrote:
> >> At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
> >> >On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
> >> > > As far as I can tell, the result of the calculation should be
> >> > > independent of daylight savings (e.g., always 5 for
> >US/Eastern).
> >> >
> >> >Then the calculation must be wrong, since EDT is -0400. EST is
> >-0500.
> >>
> >> How is the calculation wrong? It should be 5, it is 5, I don't
> >see
> >> the problem.
> >
> >Only if you collect DT as +0100 in a seperate operation, and use the
> >net result (-0400) when computing between LT and ST.
>
> I wasn't referring to the usage of the value, I was referring to the
> calculation itself. Brian said it was independent of DST, and
> produced 5 for US/Eastern. Roy said the calculation must be wrong
> since EDT is -0400, which makes no sense.
Well, at this point, I don't understand what the heck you guys are talking
about. The patch introduced a cache for the gmtoffset which, just as it
is named, represents the time difference from GMT/UTC to local time. Right?
For a system located in Maryland, USA, the gmtoffset is negative four hours
during daylight time and negative five hours during standard time, so if
you store a cached value of the offset then the value is going to be
four or five. If the calculation always results in five, then obviously
something is wrong. Either the calculation is wrong or what it is
calculating is not the gmtoffset.
I don't particularly care how it works -- I just want to see its behavior
documented if the value is cached during EDT but used during EST; i.e.,
what happens when the cached value is stale.
Alternatively, if you are storing only the standard offset and a value
for the daylight time separately, then how do we know when the daylight
time has changed?
....Roy
Re: [PATCH] performance fix for time offset computation
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 10:05 AM 08/29/2001, William A Rowe wrote:
> > At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
> > >On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
> > > > As far as I can tell, the result of the calculation should be
> > > > independent of daylight savings (e.g., always 5 for
> US/Eastern).
> > >
> > >Then the calculation must be wrong, since EDT is -0400. EST is
> -0500.
> >
> > How is the calculation wrong? It should be 5, it is 5, I don't
> see
> > the problem.
>
>Only if you collect DT as +0100 in a seperate operation, and use the
>net result (-0400) when computing between LT and ST.
I wasn't referring to the usage of the value, I was referring to the
calculation itself. Brian said it was independent of DST, and
produced 5 for US/Eastern. Roy said the calculation must be wrong
since EDT is -0400, which makes no sense.
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: [PATCH] performance fix for time offset computation
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 07:36 PM 08/28/2001, Roy T. Fielding wrote:
>On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
> > As far as I can tell, the result of the calculation should be
> > independent of daylight savings (e.g., always 5 for US/Eastern).
>
>Then the calculation must be wrong, since EDT is -0400. EST is -0500.
How is the calculation wrong? It should be 5, it is 5, I don't see
the problem.
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: [PATCH] performance fix for time offset computation
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Aug 28, 2001 at 03:16:42PM -0700, Brian Pane wrote:
> Roy T. Fielding wrote:
>
> >On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> >
> >>Here's a new version of the get_offset patch that initializes
> >>the TZ offset from apr_initialize. I've attached the new include
> >>file that it uses, apr/include/arch/unix/internal_time.h
> >>
> >
> >Out of curiosity, what happens when we switch from standard to
> >daylight time, or vice versa? Does the calculation become wrong
> >until the current child is replaced?
> >
> As far as I can tell, the result of the calculation should be
> independent of daylight savings (e.g., always 5 for US/Eastern).
Then the calculation must be wrong, since EDT is -0400. EST is -0500.
....Roy
Re: [PATCH] performance fix for time offset computation
Posted by Brian Pane <bp...@pacbell.net>.
Roy T. Fielding wrote:
>On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
>
>>Here's a new version of the get_offset patch that initializes
>>the TZ offset from apr_initialize. I've attached the new include
>>file that it uses, apr/include/arch/unix/internal_time.h
>>
>
>Out of curiosity, what happens when we switch from standard to
>daylight time, or vice versa? Does the calculation become wrong
>until the current child is replaced?
>
As far as I can tell, the result of the calculation should be
independent of daylight savings (e.g., always 5 for US/Eastern).
--Brian
Re: [PATCH] performance fix for time offset computation
Posted by Brian Pane <bp...@pacbell.net>.
Roy T. Fielding wrote:
>On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
>
>>Here's a new version of the get_offset patch that initializes
>>the TZ offset from apr_initialize. I've attached the new include
>>file that it uses, apr/include/arch/unix/internal_time.h
>>
>
>Out of curiosity, what happens when we switch from standard to
>daylight time, or vice versa? Does the calculation become wrong
>until the current child is replaced?
>
The calculation, as far as I can tell, should be DST-independent (so that
it always yields 5 for US/Eastern, for example).
--Brian
Re: [PATCH] performance fix for time offset computation
Posted by "Roy T. Fielding" <fi...@ebuilt.com>.
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> Here's a new version of the get_offset patch that initializes
> the TZ offset from apr_initialize. I've attached the new include
> file that it uses, apr/include/arch/unix/internal_time.h
Out of curiosity, what happens when we switch from standard to
daylight time, or vice versa? Does the calculation become wrong
until the current child is replaced?
I don't think it matters much, since the only local time that we generate
is for the error_log (AFAIK), but we should document the behavior.
....Roy
Re: [PATCH] performance fix for time offset computation
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Aug 28, 2001 at 11:15:41AM -0700, Brian Pane wrote:
> Here's a new version of the get_offset patch that initializes
> the TZ offset from apr_initialize. I've attached the new include
> file that it uses, apr/include/arch/unix/internal_time.h
I don't like Ryan's suggestion for a whole new header just to prototype a
single function. Lets used arch/unix/misc.h for this instead.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
[PATCH] performance fix for time offset computation
Posted by Brian Pane <bp...@pacbell.net>.
Here's a new version of the get_offset patch that initializes
the TZ offset from apr_initialize. I've attached the new include
file that it uses, apr/include/arch/unix/internal_time.h
--Brian
Index: apr/misc/unix/start.c
===================================================================
RCS file: /home/cvspublic/apr/misc/unix/start.c,v
retrieving revision 1.52
diff -u -r1.52 start.c
--- apr/misc/unix/start.c 2001/08/02 22:27:02 1.52
+++ apr/misc/unix/start.c 2001/08/28 18:11:54
@@ -60,7 +60,9 @@
#include "misc.h" /* for WSAHighByte / WSALowByte */
#include "locks.h" /* for apr_unix_setup_lock() */
+#include "internal_time.h"
+
static int initialized = 0;
static apr_pool_t *global_apr_pool;
@@ -83,6 +85,7 @@
#if !defined(BEOS) && !defined(OS2) && !defined(WIN32) && !defined(NETWARE)
apr_unix_setup_lock();
+ apr_unix_setup_time();
#elif defined WIN32 || defined(NETWARE)
iVersionRequested = MAKEWORD(WSAHighByte, WSALowByte);
err = WSAStartup((WORD) iVersionRequested, &wsaData);
Index: apr/time/unix/time.c
===================================================================
RCS file: /home/cvspublic/apr/time/unix/time.c,v
retrieving revision 1.51
diff -u -r1.51 time.c
--- apr/time/unix/time.c 2001/08/10 21:04:49 1.51
+++ apr/time/unix/time.c 2001/08/28 18:11:54
@@ -70,6 +70,10 @@
#endif
/* End System Headers */
+#if !defined(HAVE_GMTOFF) && !defined(HAVE___OFFSET)
+static apr_int32_t server_gmt_offset;
+#endif /* if !defined(HAVE_GMTOFF) && !defined(HAVE___OFFSET) */
+
static apr_int32_t get_offset(struct tm *tm)
{
#ifdef HAVE_GMTOFF
@@ -77,30 +81,8 @@
#elif defined(HAVE___OFFSET)
return tm->__tm_gmtoff;
#else
- /* We don't have an offset field to use, so calculate it.
- mktime() is the inverse of localtime(); so, presumably,
- passing in a struct tm made by gmtime() let's us calculate
- the true GMT offset. However, there's a catch: if daylight
- savings is in effect, gmtime()will set the tm_isdst field
- and confuse mktime() into returning a time that's offset
- by one hour. In that case, we must adjust the calculated GMT
- offset. */
- {
- time_t t1 = time(0), t2 = 0;
- struct tm t;
- int was_dst;
-
-#if APR_HAS_THREADS && defined(_POSIX_THREAD_SAFE_FUNCTIONS)
- gmtime_r(&t1, &t);
-#else
- t = *gmtime(&t1);
+ return server_gmt_offset;
#endif
- was_dst = (t.tm_isdst > 0);
- t.tm_isdst = -1;
- t2 = mktime(&t);
- return (apr_int32_t) difftime(t1, t2) + (was_dst ? 3600 : 0);
- }
-#endif
}
APR_DECLARE(apr_status_t) apr_ansi_time_to_apr_time(apr_time_t *result,
@@ -308,3 +290,37 @@
return APR_SUCCESS;
}
#endif
+
+APR_DECLARE(void) apr_unix_setup_time(void)
+{
+#if !defined(HAVE_GMTOFF) && !defined(HAVE___OFFSET)
+ /* Precompute the offset from GMT on systems where it's not
+ in struct tm.
+ mktime() is the inverse of localtime(); so, presumably,
+ passing in a struct tm made by gmtime() let's us calculate
+ the true GMT offset. However, there's a catch: if daylight
+ savings is in effect, gmtime()will set the tm_isdst field
+ and confuse mktime() into returning a time that's offset
+ by one hour. In that case, we must adjust the calculated GMT
+ offset. */
+
+ struct timeval now;
+ time_t t1, t2;
+ struct tm t;
+ int was_dst;
+
+ gettimeofday(&now, NULL);
+ t1 = now.tv_sec;
+ t2 = 0;
+
+#if APR_HAS_THREADS && defined(_POSIX_THREAD_SAFE_FUNCTIONS)
+ gmtime_r(&t1, &t);
+#else
+ t = *gmtime(&t1);
+#endif
+ was_dst = (t.tm_isdst > 0);
+ t.tm_isdst = -1;
+ t2 = mktime(&t);
+ server_gmt_offset = (apr_int32_t) difftime(t1, t2) + (was_dst ?
3600 : 0);
+#endif
+}
Re: [PATCH] performance fix for time offset computation
Posted by Jeff Trawick <tr...@attglobal.net>.
Brian Pane <bp...@pacbell.net> writes:
> On platforms where neither HAVE_GMTOFF nor HAVE___OFFSET is defined,
> like Solaris, the function "get_offset" in apr/time/unix/time.c is a
> bottleneck in time formatting.
>
> On these platforms, get_offset ignores its argument; it really computes
> the server's offset from GMT, normalized so that it's independent of
> daylight savings.
>
> The following patch caches the offset after it's first computed, so
> that we don't have to compute it repeatedly.
Would anybody besides me feel better if we had apr_initialize() call
apr_unix_setup_time() to do this?
--
Jeff Trawick | trawick@attglobal.net | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...