apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Bloom <...@ntrnet.net>
Subject Re: [PATCH] possible optimization in apr_poll()?
Date Mon, 15 Jul 2002 04:34:28 GMT

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                        	rbb@apache.org
550 Jean St
Oakland CA 94610
-------------------------------------------------------------------------------


Mime
View raw message