Interesting point. I tried it with a 300MB file, using Cygwin grep, and searching for a fixed string with various settings. I repeated each run 3 times. Here the times

with -F:

Code:

0.27s user 0.08s system 91% cpu 0.372 total

0.30s user 0.05s system 93% cpu 0.367 total

0.28s user 0.06s system 95% cpu 0.358 total

without option:

Code:

0.22s user 0.14s system 98% cpu 0.362 total

0.31s user 0.05s system 98% cpu 0.363 total

0.22s user 0.12s system 95% cpu 0.358 total

with -E:

Code:

0.25s user 0.09s system 93% cpu 0.367 total

0.27s user 0.08s system 95% cpu 0.359 total

0.25s user 0.11s system 98% cpu 0.365 total

Of course, it could be that the amount of data is not massive enough to show a significant difference; or that the I/O of the Cygwin layer is so heavy, that it shadows performance differences. Or that gnu grep is clever enough to recognize, that the pattern does not contain any regexp characters and does internally a '-F' always.

To evaluate at the last hypothesis, I replaced the pattern by one which really contained an extended regexp instead of a fixed string (using a .+ regexp operation). In this case, the times were systematically higher, but not very much:

Code:

0.37s user 0.11s system 99% cpu 0.486 total

0.36s user 0.09s system 93% cpu 0.481 total

0.30s user 0.14s system 89% cpu 0.486 total

Perhaps such a test should really be repeated with a file which is several GB in size.

Interestingly, in the OP's problem, the whole content of the file was stored in a shell variable, and this makes me wonder, where the practical limit is for the content of a variable in, say, bash or ksh...