author | Junio C Hamano <gitster@pobox.com> | |
Wed, 13 Jan 2010 03:21:46 +0000 (19:21 -0800) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Wed, 13 Jan 2010 09:05:04 +0000 (01:05 -0800) | ||
commit | 885d211e714b3787cd059e347694f9b24e1db1f3 | |
tree | 1ae652d1f908637edef8c1ca592223bc99c8adc2 | tree | snapshot |
parent | bbc09c22b9f7784b1aab71d4876227956e6e8f4f | commit | diff |
grep: rip out pessimization to use fixmatch()
Even when running without the -F (--fixed-strings) option, we checked the
pattern and used fixmatch() codepath when it does not contain any regex
magic. Finding fixed strings with strstr() surely must be faster than
running the regular expression crud.
Not so. It turns out that on some libc implementations, using the
regcomp()/regexec() pair is a lot faster than running strstr() and
strcasestr() the fixmatch() codepath uses. Drop the optimization and use
the fixmatch() codepath only when the user explicitly asked for it with
the -F option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Even when running without the -F (--fixed-strings) option, we checked the
pattern and used fixmatch() codepath when it does not contain any regex
magic. Finding fixed strings with strstr() surely must be faster than
running the regular expression crud.
Not so. It turns out that on some libc implementations, using the
regcomp()/regexec() pair is a lot faster than running strstr() and
strcasestr() the fixmatch() codepath uses. Drop the optimization and use
the fixmatch() codepath only when the user explicitly asked for it with
the -F option.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
grep.c | diff | blob | history |