apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Why not POSIX time_t?
Date Mon, 15 Jul 2002 15:36:56 GMT
+1 (on both :) )

David Reid wrote:
> 
> +1 from me. Let's finish this nonsense!
> 
> david
> 
> > 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
> > >
> > >
> > >
> >
> >
> >
> >
> 
> 
> 


-- 
===========================================================================
   Jim Jagielski   [|]   jim@jaguNET.com   [|]   http://www.jaguNET.com/
      "A society that will trade a little liberty for a little order
             will lose both and deserve neither" - T.Jefferson

Mime
View raw message