On Mon, 15 Jul 2002, Bill Stoddard wrote:
> > 1. gettimeofday
> > (fast, no loss of accuracy)
> We cannot avoid this, right?
Right.
>
> > 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.
Rather than having to do (seconds * 1000000 + microseconds), you just do
((seconds << 20)  binarymicroseconds).
> > 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?
It's not always smaller:
30 seconds = 30,000,000 microseconds
30000000 base 10 = 11100 1001110000 1110000000 base 2
11100 1001110000 1110000000 >> 20 = 11100 base 2
11100 base 2 = 28 base 10
So your approximation of 30 seconds gets turned into 28 seconds. Oops.
You'd have to do lots of extra work to make sure you always accounted for
the "lost" 48576 microseconds per second. I've been thinking about it all
day and have yet to come up with a nondividing way to do that.
> I must have blinked... How does step 2 work with busec?
See above.
> I think apr_time_t works for Cliff now (Cliff am I mistaken?) and I am
> proposing that we not change apr_time_t... So I must be missing something.
It works for me as long as apr_time_now() [and apr_time_sub() should we
decide we need one for some silly reason] can give me a resolution of at
least tenths or hundredths of milliseconds. So yes, apr_time_t works for
me now. So would struct timeval, but it would be more of a pain. time_t
clearly would *not* work for me.
Cliff
