On Thu, 2003-07-03 at 07:31, [EMAIL PROTECTED] 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
Pros:
Time arithmetic is fast
Cons:
Extracting the seconds is slow
2. Binary microseconds
How it works:
Time is stored in a 64-bit int as
(time_t << 22) + microseconds
Pros:
Extracting the seconds is fast
Cons:
Extracting the microseconds is slow
3. Stop storing microseconds
How it works:
Time is stored as time_t, with no microseconds
Pros:
Works great for apps that only need seconds
No 64-bit multiplication/division performance
problems
Cons:
Doesn't work so well for apps that do need
microseconds
4. Struct
How it works:
Time is stored as a struct with separate fields
for seconds and microseconds
Pros:
Extracting seconds is fast
Cons:
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:
http://marc.theaimsgroup.com/?m=102678180413988
Brian
