> 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?
This would be a big improvement. A shift is a -lot- cheaper than a 64 bit division. We could leave apr_time_t exactly as it is today and use techniques like this to solve the performance problem. Perhaps use a better (more accurate) hurestic to take resolution out of apr_time_t. I see nothing wrong with this approach and think we should actively consider it. Bill > > 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 > ------------------------------------------------------------------ > ------------- >