At 10:14 PM 6/10/2002, Brian Pane wrote:
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 \
                                           + (usec * 1000000) / APR_USEC_PER_SEC)

#define APR_TIME_SEC(time) ((time) / APR_BUSEC_PER_SEC)

#define APR_TIME_USEC(time) ((((usec) % APR_BUSEC_PER_SEC)  \
                                          * 1000000) / 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.