apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Stoddard" <b...@wstoddard.com>
Subject RE: [PATCH] example BUSEC patch for benchmarking only
Date Thu, 11 Jul 2002 01:34:37 GMT
> > 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

Mime
View raw message