apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject RE: [PATCH 2] example binary BUSEC patch for benchmarking only
Date Thu, 11 Jul 2002 16:31:28 GMT
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



Mime
View raw message