On Mon, 11 Jan 2010, Fredrik Kuivinen wrote:
quoted
Try a complex pattern ("qwerty.*as" finds the same line), and see if that
too is slower than before. If that is faster than it used to be (with
--no-ext-grep, of course), then it's strstr() that is badly implemented.
Ah, yes, that's it. With the pattern "qwerty.*as" I get 2.5s with the
patch and 6s without.
Ok, so on your machine, regcomp() is basically twice as fast as strstr().
Which is not entirely unexpected: I was actually surprised by strstr()
being apparently so good on my machine. I do not generally expect things
like that to be at all optimized for bigger working sets. Most common uses
of strstr() are in short strings - not "strings" that are many kilobytes
in size (the whole file).
In fact, I suspect it works so well for me because in my version of glibc
it's not just SSE-optimized: judging by the naming it's SSE4.2 optimized -
so the case I see on my machine will _only_ happen on Nehalem-based cores
(ie the new "Core i[357]" cpu's).
It is entirely possible that strstr in general is a disaster.
Linus