This will work, and should be portable. Just a question, how big a
performance improvement is this? Have we hit the point where we are
optimizing code just to optimize code?
I would not support this change, simply because I don't see it making a
huge difference. We are better off fixing the apr_time_t implementation
and then looking for things like this.
Ryan
> Is this at all portable? I'm making the approximation that n>>10 is
> about the same as a /1000, and since apr_poll() isn't guaranteed to be
> that accurate, this should be a good chance for an optimization, right?
>
> -aaron
>
>
> Index: srclib/apr/poll/unix/poll.c
> ===================================================================
> RCS file: /home/cvs/apr/poll/unix/poll.c,v
> retrieving revision 1.6
> diff -u -r1.6 poll.c
> --- srclib/apr/poll/unix/poll.c 13 Jul 2002 06:31:52 -0000 1.6
> +++ srclib/apr/poll/unix/poll.c 15 Jul 2002 03:46:25 -0000
> @@ -128,7 +128,7 @@
> }
>
> if (timeout > 0) {
> - timeout /= 1000; /* convert microseconds to milliseconds */
> + timeout >>= 10; /* approximate "/= 1000" to convert to milliseconds
> */
> }
>
> i = poll(pollset, num, timeout);
>
--
_______________________________________________________________________________
Ryan Bloom [EMAIL PROTECTED]
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------
