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. 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?
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. 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.
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 64-bit multiplication with
a 64-bit 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 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
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.
--Brian
