William A. Rowe, Jr. wrote:
At 09:31 PM 6/10/2002, I wrote:
usec * 1048575 / 1000000 = busec
bsec * 1000000 / 1048575 = usec
whoops, s/1048575/1048576/
That's a major improvement. I was going to complain about
the need for both a 64-bit multiplication and a 64-bit
division to do the conversion, but 1048576 only requires a
shift.
In general, I like this design:
* It combines most of the benefits of the "struct apr_timeval"
approach with most of the benefits of the current seconds*1000000+microseconds
scalar representation.
However, we aught to define convenience macros;
#define APR_BUSEC_PER_SEC 1048576
#define APR_TIME_MAKE(sec, usec) (sec * APR_BUSEC_PER_SEC \
#define APR_TIME_SEC(time) ((time) / APR_BUSEC_PER_SEC)
#define APR_TIME_USEC(time) ((((usec) % APR_BUSEC_PER_SEC) \
* And the transition is easy: just change APR_USEC_PER_SEC to 1048576
and tell all users of APR to recompile.
Not quite, simply dividing the time by APR_USEC_PER_SEC would give you seconds,
but taking the modulus APR_USEC_PER_SEC wouldn't give you decimal usec.
This is why I'd favor using APR_BUSEC_PER_SEC for the name, to prevent new
confusion
+1 for the binary microseconds implementation
-0 for continuing to call it apr_time_t
So it's time to invent the proper, new names and give it a whirl. I'll commit such a patch
later tonight or so, depending on how things are going. Feel free to beat me to it :-)
If we make it conditional on a compile switch, we can benchmark the difference.
