> From: Bill Stoddard [mailto:[EMAIL PROTECTED]
>
>
> > 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-
> 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 exact
[EMAIL PROTECTED] wrote:
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.
I agree. Once we go to the binary microsecond implementation,
what we'll be able t
> >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.
> >
>
> I agree. Once we go to the binary microsecond implementation,
> what we'll be able to do within
Ryan Bloom wrote:
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?
Based on the profile data, 64-bit divisions *are* a problem,
but I think there's a better solution for th
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 ap
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
===
