> > 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.
ie, turn the division into a shift, which is much less expensive. Bill
