apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: Why not POSIX time_t?
Date Mon, 15 Jul 2002 17:32:49 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)
We cannot avoid this, right?

>     2. 64-bit multiplication to build an apr_time_t
>        (slow (on lots of current platforms), no loss of accuracy)

Do we eliminate this by representing apr_time_t as busec?

>     3. 64-bit shifts to get approximate seconds
>        (fast, but loss of accuracy)

If you convert from microseconds to integer seconds (which is what httpd
requires), you loose -resolution- no matter how you do it. If the accuracy
you loose is smaller than the resolution, then what does it matter that you
loose some 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.

I must have blinked... How does step 2 work with busec?

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

I think apr_time_t works for Cliff now (Cliff am I mistaken?) and I am
proposing that we not change apr_time_t... So I must be missing something.

I'd like to leave the struct/function renames off the table for now and just
discuss the technical details of the proposals... It was the intertwining of
the technical and esthetics of the naming convestions that made the previous
discussion difficult for me to follow.


View raw message