[ Bringing this back on-list where it belongs... ]
On Wed, Sep 05, 2001 at 03:37:42PM -0700, Brian Pane wrote:
> Ian Holsman wrote:
>
> >On Wed, 2001-09-05 at 15:20, Brian Pane wrote:
> >
> >>Ian Holsman wrote:
> >>
> >>>Ok..
> >>>test is in there now...
> >>>with justin's patch.
> >>>I haven't tested the functionality of it, but the performance looks
> >>>good.
> >>>
> >>Yes indeed. Any idea how this code compares to your skip-5 implementation?
> >>
> >* looks much neater.
> >* just optimizes the 'start_tag', which make it's life easier.
> >* does the same kind of thing as the skip-5
> >* the edge case is handled the 'slow' way..which is good, as it gets
> > around most of the buggy crap I had in my stuff
> >
> >* why is it compiling the pattern inside of the 'find_start_sequence'
> >this could be done 'postconfig' or in 'child_init'
I'm lazy? I'll clean it up and post it once more to the list to give
people a chance to review before I commit. This is a pretty big
change, but I think we're going in the right direction though.
> >otherwise
> >+1
Coolie. (Although your vote isn't binding, it is valuable feedback.)
[ Brian's comments ]
> Sounds good. Two concerns:
>
> * Should we run it through Quantify? (As good as the reduction in
> usr CPU in the graphs is, I'm slightly surprised that it's not even
> better.)
I'll wait until we have some Quantify numbers to ensure that this is
a better performing algorithm. This is also with Sascha's hacked
up implementation of bndm. Someone who knows the bndm algorithm
well should verify it. (It looks like it works from everything I
can tell...)
> * We seem to have hit a wall at ~250 requests/second in the mstone
> environment with includes, ~300 without. I'm worried that there
> may be another bottleneck somewhere else in the server. (But figuring
> that out needn't get in the way of Justin's patch.)
Be curious to see why. I wonder if the time is still spent in
find_start_sequence now. Ideally, as we uncover bottlenecks,
we should just find more. We keep going until we find no more. =)
-- justin
