> >> 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?
> >
>
> 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.
>
Cliff demonstrates that there is significant loss of accuracy using just a
shift. I believe (faith? :-) that there is a simple solution to this. Don't
know what it is just now though...
<snip>
>
> >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 general-purpose solution because it can't
> hold microseconds
>
> * Scalar containing seconds and usec, encoded in the current
> apr_time_t format:
> Pros: Microsecond resolution
> Cons: 64-bit 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
fast retrival of binary seconds. Need to convert to decimal to
pass on apr_poll, et. al., no?
> 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 (64-bit seconds plus 32-bit 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 here--corrections welcome), I think the binary
> microseconds design is the best.
>
If it is not possible to efficiently extract accurate 1 second resolution
values from apr_time_t (decimal microseconds), then I agree. I am not quite
ready to conceed the point though.
Bill
