Bill Stoddard wrote:
>>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?
>
Right (but it's fast enough that we don't need to worry about it).
>> 2. 64bit 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?
>
Yes. Representing apr_time_t as busec is, from my perspective,
the ideal solution: we get speed and accuracy, while still
providing microsecond resolution to those apps that need it.
>> 3. 64bit 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?
>
I think it's possible to see inaccuracies at the second level if
we divide the current time_t by 2^20. If not, then this concern
vanishes.
>>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?
>
With busec, step 2 replaces the 64bit multiplication with
a 64bit shift.
>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.
>
I agree on this part. Looking just at the proposals I've heard so
far for the representation, and ignoring the naming issues, here's
my attempt to enumerate the advantages and drawbacks of each
representation:
* Scalar containing seconds since the epoch (like time_t):
Pros: Adequate for things that only need seconds,
extracting seconds from this object has zero cost :)
Cons: Not a generalpurpose solution because it can't
hold microseconds
* Scalar containing seconds and usec, encoded in the current
apr_time_t format:
Pros: Microsecond resolution
Cons: 64bit multiplication and division ops are a
performance problem in some important applications
(like the httpd)
* Scalar containing seconds and usec, encoded in busec format:
Pros: Microsecond resolution, fast retrieval of seconds and
microseconds
Cons: None that I know of
* Struct containing seconds and usec as separate fields
Pros: Microsecond resolution, fast retrieval of seconds and
microseconds
Cons: May take up more space (64bit seconds plus 32bit usec,
compared to 64 bits for the whole object in some of
the other designs), addition and subtraction are slower
with a struct than with a scalar.
Based on the technical merits of these designs (which I hope I've
described accurately herecorrections welcome), I think the binary
microseconds design is the best.
Brian
