apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Bloom" <...@covalent.net>
Subject RE: Why not POSIX time_t?
Date Mon, 15 Jul 2002 13:55:31 GMT
> >>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