Brian, fix is commit soon. Ryan
---------------------------------------------- Ryan Bloom [EMAIL PROTECTED] 645 Howard St. [EMAIL PROTECTED] San Francisco, CA > -----Original Message----- > From: Brian Pane [mailto:[EMAIL PROTECTED] > Sent: Thursday, July 11, 2002 9:31 AM > To: APR Development List > Subject: RE: [PATCH 2] example binary BUSEC patch for benchmarking only > > On Thu, 2002-07-11 at 06:58, Bill Stoddard wrote: > > I ran a quick profile with this patch and it eliminated a couple of > > divisions (calls to __divi64 reduced from 4 to 2 in my test setup. your > > mileage may vary) which was good for 493 instructions. Still have 3 > __divu64 > > and 2 __divi64 calls. The three __divu64 calls are in the gettimeofday() > CRT > > function, so there is not much we can do about these directly. One > __divi64 > > is in apr_poll (convert microseconds to milliseconds. This can probably > be > > optimized away). The other __divi64 is somewhere in cached_explode > > (util_time.c). > > With the cached_explode() division now fixed, I just looked at the > division in apr_poll(). The code that's there now is doing the math > like this: > > if (timeout > 0) { > timeout /= 1000; /* convert microseconds to milliseconds */ > } > > It's assuming that timeout, an apr_interval_time_t, represents an > absolute time in microseconds--but that may not be true much longer > if we switch to binary microseconds. The calculation should be > something like: > > timeout_msec = apr_time_usec(timeout) / 1000; > timeout_sec = apr_time_sec(timeout); > if (timeout_sec) { > timeout_msec += 1000 * timeout_sec; > } > > I don't see a way to eliminate the "/ 1000" to convert usec to > msec. But we may be able to do all the math in 32-bit mode, by > limiting the maximum timeout to the number of milliseconds that > will fit in 32 bits, which works out to a max timeout of about > 50 days. > > --Brian >
