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 15:08:38 GMT
++1 here.

Ryan

----------------------------------------------
Ryan Bloom                  rbb@covalent.net
645 Howard St.              rbb@apache.org
San Francisco, CA 

> -----Original Message-----
> From: David Reid [mailto:dreid@jetnet.co.uk]
> Sent: Monday, July 15, 2002 8:00 AM
> To: APR Dev List
> Subject: Re: Why not POSIX time_t?
> 
> +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
> > >
> > >
> > >
> >
> >
> >
> >
> 
> 



Mime
View raw message