httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dean gaudet <dgaudet-list-new-ht...@arctic.org>
Subject Re: SGI Patch 10xpatch-2.0a6-2: Reduce time resolution to 1 sec
Date Fri, 23 Feb 2001 21:12:12 GMT
On Fri, 23 Feb 2001, Roy T. Fielding wrote:

> > That's how it it was originally.  It was changed to this model not long
> > after the original code was committed.  One of the problems with using
> > seconds and a separate microsecond field, is that platforms other than
> > Unix don't have the same reliance on seconds.  I believe Windows uses 100
> > nanosecond blocks.
>
> I realize that, but APR will be faster and considerably less bug-prone
> on both platforms if the time structure contains one variable for
> seconds and one for microseconds, regardless of how the time was
> generated.

APR needs to be written and made correct once.  there will be more folks
using APR than there are needs to fix the time code within APR.

time arithmetic is way easier on a single scalar than it is on multiple
scalars.  contrast:

	diff = now - then;

vs.

	diff.sec = now.sec - then.sec;
	long tmp = (long)now.usec - (long)then.usec;
	if (tmp < 0) {
		tmp += 1000000;
		--diff.sec;
	}
	diff.usec = tmp;

> If you want to really optimize it for speed, include a third
> variable for the native OS time_t, and a const char * for storing the
> rfc822 date string the first time it is converted.

my change to a single scalar was not an optimisation, it was intended
to make it more likely that users of APR would generate correct time
arithmetic.  i'm frequently willing to throw away small amounts
of performance if it's more likely folks will write correct code.

the performance bug is not the APR time representation -- it's the httpd
code which calls ap_now() for every single request and then does all
the module 10 arithmetic to format it into a Date: and log timestamp.

the solution that all the performance winning webservers use is a
separate thread which wakes up once a second to generate new base-10
representations of the time.

now that 2.0 has all the zero-copy machinery i think you've got what
you need to share the timestamp strings amongst multiple threads without
worrying about the safety issues.  (bill's suggested two buffer method
works fine unless you for some reason have a task sleep for 2 seconds...
such as when a system is under a hellish load.)

> Regardless, APR and httpd have assumptions strewn throughout the code
> that apr_time_t is a long long in microseconds, which isn't native
> on any platform and makes every time operation slower for no reason.

either you spread code around which assumes that you've got two fields,
one seconds and one microseconds, or you assume that you've got one field
in microseconds.  i don't see how either assumption is any worse than the
other.

-dean


Mime
View raw message