* Jamal Hadi Salim <1115470985.19561.58.camel@xxxxxxxxxxxxxxxxxxxxx> 2005-05-07
09:03
> On Fri, 2005-06-05 at 16:43 +0200, Thomas Graf wrote:
>
> > As you can see, it expects a char * in args[0] and the length of it
> > in args[1]. All it does is check whether all bytes have been read
> > already and if not return the remaining part of the buffer so even
> > if the search algorithm can't consume all the bytes returned it will
> > still work as expected.
> >
>
> Ok, makes sense - in the case of a string spanning multi skbs, i suppose
> it wouldnt matter, correct?
Strings spanning multiple skbs can be handled just like a paged skbs
_iff_ all skbs are known at the point the search starts, otherwise
we'll need more trickering.
> Sorry - I thought you were talking about pre-fetching text as in
> lookahead for text in a regexp state machine.
> I am not sure i see the L1 cache connection. Both seem to have tight for
> loops and depending on the algorithm there would be no difference
> in cache warmth afaics. Infact your scheme may suffer more because it
> has a lot of stuff on the stack. However, playing around with the code
> is the only way to find out.
You're probably right, I suspect mine to perform better because in a
typical search there is less work to do per loop and the interruption
to fetch the next block of text is less intrusive. Time will tell.
|