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 <jim@meyering.net>
To: Z. Majeed <zmajeed@sbcglobal.net> 
Cc: "15630@debbugs.gnu.org" <15630@debbugs.gnu.org> 
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 <zmajeed@sbcglobal.net> 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.