Re: [PATCH] grep: do not do external grep on skip-worktree entries
- From
Fredrik Kuivinen <frekui@gmail.com>
- Date
- Jan 11, 2010, 21:07 UTC
- Message-ID
- <4c8ef71001111307q6679039ajbef22f2e1748df56@mail.gmail.com>
- In-Reply-To
- <alpine.LFD.2.00.1001111159270.17145@localhost.localdomain>
On Mon, Jan 11, 2010 at 21:07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
Show 12 quoted lines
>
>
> On Mon, 11 Jan 2010, Fredrik Kuivinen wrote:
>> >
>> > 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().Yes.
Show 12 quoted lines
> 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.
Another option is to use memmem instead. As we know the length of the buffer already it should be a slight improvement over strstr for everyone. memmem may cause some portability problems though as it is a GNU extension.
I get these results: (git-grep --no-ext-grep qwerty, best of five)
Junio's patch: 0:04.84 memmem (attached patch on top of Junio's): 0:02.91 regcomp/regexec (I changed is_fixed to always return 0, also on top of Junio's): 0:02.02
- Fredrik