apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bri...@apache.org>
Subject Re: Why not POSIX time_t?
Date Mon, 15 Jul 2002 18:19:00 GMT
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



Mime
View raw message