apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <brian.p...@cnet.com>
Subject Re: remaining issues prior to 1.0?
Date Sun, 31 Aug 2003 21:57:55 GMT
On Thu, 2003-07-03 at 07:31, gregames@apache.org wrote:
> Brian Pane wrote:
> >> What are the real issues stopping us from releasing APR 1.0?  
> > We still have the 64-bit divisions in the apr_time_t code.
> It sure would be nice to make this one go away since it is most likely an API 
> change.  But what are the chances we can come to a consensus on how to do it in 
> a reasonable time?  Does someone have an objective summary of the proposals we 
> could look at, hopefully without starting a flame war?

Here's my attempt at summarizing all the proposals.
There was a lot of debate about the naming of the time
type--whether it was good or bad to give it a name so
similar to time_t, whether the type name should reflect
an implementation like binary microseconds, etc.  For
simplicity, I'll just describe the implementations as
I remember them, independent of the naming issues.

1. Current design
    How it works:
      Time is stored in a 64-bit int as
      (time_t * 1,000,000) + microseconds
      Time arithmetic is fast
      Extracting the seconds is slow

2. Binary microseconds
    How it works:
      Time is stored in a 64-bit int as
      (time_t << 22) + microseconds
      Extracting the seconds is fast
      Extracting the microseconds is slow

3. Stop storing microseconds
    How it works:
      Time is stored as time_t, with no microseconds
      Works great for apps that only need seconds
      No 64-bit multiplication/division performance
      Doesn't work so well for apps that do need

4. Struct
    How it works:
      Time is stored as a struct with separate fields
      for seconds and microseconds
      Extracting seconds is fast
      Time arithmetic is slow

The pros and cons are tricky; the performance tradeoffs
that are ideal for one app may be unbearable for another.
The last time this topic came up, I ended up being in
favor of a variant of option 3:


View raw message