apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: Why not POSIX time_t?
Date Mon, 15 Jul 2002 14:38:55 GMT
New proposal... leave apr_time_t exactly as it is.  The performance problem
is with how we are converting an apr_time_t into a value with 1 second
resolution (ie, doing 64 bit divisions).  I propose we introduce some new
macros (or functions) to efficiently remove resolution from apr_time_t and
do an approximate (not precise) conversion to seconds.  Aaron (I believe)
has already demonstrated this idea.  This is the least invasive, easiest to
understand and workable solution IMHO.

Bill

> > >>If you mean using only second-resolution times, that's an option,
> > >>but not for the httpd.  One of the big problems with 1.3 was that
> > >>the request time was only stored with 1-second resolution.  We used
> > >>to have to add in custom, redundant time lookups to get better
> > >>resolution whenever we needed to instrument request duration or
> > >>log request times with higher precision.
> > >>
> > >>
> > >
> > >But http only requires 1 sec resolution.  If you want better than
> that,
> > >then you will have a performance hit.
> > >
> >
> > No you won't.  It's *faster* to get the time with
> > microsecond resolution than to get it with second
> > resolution.  (gettimeofday() is faster than time().)
>
> Then get the time with microsecond resolution in the thread, but only
> save second resolution.  This way, the 64-bit division is not happening
> in the middle of request processing.
>
> > >  But what
> > >you just said is that time code is not a performance problem.
> > >
> >
> > No, I said the retrieval of the time (the thing for which you're
> > proposing a separate thread) is not a performance bottleneck.
> >
> > >  So, why are
> > >we optimzing this again?
> > >
> >
> > Because 64-bit divisions are a performance problem, as
> > seen in FirstBill's recent benchmarks.
> >
> > Looking up the time with microsecond resolution is not
> > the problem.  The problem is that we do gratuitous 64-bit
> > math once we've retrieved the time.  And the binary
> > microsecond change is a valid remedy for that problem.
>
> Yes it is, but it isn't the ONLY valid remedy.  Since that change is
> causing a lot of grief, I am asking us to consider other remedies.
>
> Ryan
>
>
>


Mime
View raw message