On Mon, 15 Jul 2002, Bill Stoddard wrote: > > 1. gettimeofday > > (fast, no loss of accuracy) > We cannot avoid this, right?
Right. > > > 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. Rather than having to do (seconds * 1000000 + microseconds), you just do ((seconds << 20) | binarymicroseconds). > > 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? 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 non-dividing 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
