From: dean gaudet <[EMAIL PROTECTED]>
> 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;
>
I agree with Dean. Need to keep apr_time_t a single scalar.
> > 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.
Yep.
>
> 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.
>
Exactly!
Bill
