> At 01:14 PM 7/9/2002, you wrote: > >Bill Stoddard wrote: > >> > >>Where and when was the post that described this proposal? I'd > like to take > >>a look. Is there a patch? > > > >There's no patch that I know of, but here's the thread with wrowe's > >original proposal for the binary microseconds design: > > http://marc.theaimsgroup.com/?l=apr-dev&m=102376298728487&w=2 > > http://marc.theaimsgroup.com/?l=apr-dev&m=102383695930036&w=2 > > is a better link to some example macros. > > >With the big batch of changes that I made last week, almost all > >of the time-related code in the httpd now uses the new macros-- > >apr_time_sec(), apr_time_usec(), etc--instead of multiplying and > >dividing by 1,000,000 directly. Hopefully that will make it > >easier to try out a new time representation. > > Agreed. But even discounting that USEC_PER_SEC is used for > it's real meaning somewhere, and would introduce slight discrepancies, > attached is simply the gross hack to force busec units. > > Note the 'right' change is to have a BUSEC_PER_SEC constant, > but this is a truer test for benchmarking. > > Bill
Humm... looking at this macro which is used all over the place, I see a division. #define apr_time_sec(time) ((apr_int64_t)((time) / APR_USEC_PER_SEC)) Since APR_USEC_PER_SEC is now a binary representation, I assume the compiler will do the proper optimization. Bill
