apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: Why not POSIX time_t?
Date Mon, 15 Jul 2002 15:29:04 GMT
Bill Stoddard wrote:

>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.
>

I'm opposed to his approach because it combines the worst of
both worlds: poor performance and poor accuracy.

Under this proposal, the sequence of time operations in an
httpd request would look like:

    1. gettimeofday
       (fast, no loss of accuracy)
    2. 64-bit multiplication to build an apr_time_t
       (slow (on lots of current platforms), no loss of accuracy)
    3. 64-bit shifts to get approximate seconds
       (fast, but loss of accuracy)

We end up with compromises in both performance and accuracy,
in code that:
    - is completely under our control, and
    - wouldn't require any compromise of performance or accuracy
      if we just stopped creating the seconds*1000000+microseconds
      representation in step 2.

Things look even worse outside the httpd.  Cliff, for example,
mentioned in one of the threads last week that he uses apr_time_t
in programs that require microsecond resolution with high performance.
As long as we keep encoding apr_time_t in the current manner, APR will
never be an effective choice for such apps.

--Brian



Mime
View raw message