Thanks - I nearly always use -i so a fix would be highly appreciated - meantime I dug a bit more into this issue - it's not as straightforward as it first seemed - the crux of the problem is not the workaround for UTF-8 but -i "<name>.*russia" causing dfamust to be just the one-character string "<" because "name" turns into character classes - for XML input that practically makes keyword matching worthless and the main loop in EGexecute degenerates to line-by-line processing - it seems to me dfaparse ought to deal with case foldings a little better so the trans table support in cwexec gets used - there have also been some simple patches submitted to make use of trans in bmexec
Zartaj ________________________________ From: Jim Meyering <[email protected]> To: Z. Majeed <[email protected]> Cc: "[email protected]" <[email protected]> Sent: Saturday, October 19, 2013 8:58 PM Subject: Re: bug#15630: Acknowledgement (grep 2.14 much slower than 2.5.1) On Wed, Oct 16, 2013 at 12:20 PM, Z. Majeed <[email protected]> wrote: > I see the reason is the workaround in do_execute that turns on line-by-line > matching for -i across the board - I got runtime confirmation by trying > "<name>.*[rR][uU][sS][sS][iI][aA]" - the times were faster than for grep > 2.5.1 with -i: > 3.59user 2.95system 0:06.55elapsed > > I'm not sure if the workaround is for the -i problem in UTF-8 locales > discussed in http://savannah.gnu.org/bugs/?29391. This bug report really > should be titled "--ignore-case very slow in grep 2.14" Thanks for the reminder. I'm about to release grep-2.15, but after that, I will be inclined to address that problem.
