Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3D32EA40.4010802@apache.org>
Date: Mon, 15 Jul 2002 08:29:04 -0700
From: Brian Pane <brianp@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: APR Development List <dev@apr.apache.org>
Subject: Re: Why not POSIX time_t?
References: <JHEPKCEMGPKFFDHHDDKDOEFCEMAA.bill@wstoddard.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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