Para agregar a la excelente respuesta de Steve.
Puede que no sea muy conocido, pero grep casi siempre es más rápido cuando se busca una cadena de patrón más larga que una corta, porque en un patrón más largo, Boyer-Moore puede saltar hacia adelante en pasos más largos para lograr velocidades sublineales aún mejores :
Ejemplo:
# after running these twice to ensure apples-to-apples comparison
# (everything is in the buffer cache)
$ time grep -c 'tg=f_c' 20140910.log
28
0.168u 0.068s 0:00.26
$ time grep -c ' /cc/merchant.json tg=f_c' 20140910.log
28
0.100u 0.056s 0:00.17
¡La forma más larga es un 35% más rápida!
¿Cómo? Boyer-Moore construye una tabla de salto hacia adelante a partir de la cadena de patrones, y siempre que hay una falta de coincidencia, elige el salto más largo posible (del último carácter al primero) antes de comparar un solo carácter en la entrada con el carácter en la tabla de salto.
Aquí hay un video que explica a Boyer Moore (Crédito a kommradHomer)
Otro error común (para GNU grep) es que fgrep
es más rápido que grep
. f
in fgrep
no significa 'rápido', significa 'fijo' (ver la página de manual), y dado que ambos son el mismo programa, y ambos usan Boyer-Moore , no hay diferencia de velocidad entre ellos cuando se busca fijo- cadenas sin caracteres especiales regexp. La única que usar la razón fgrep
es cuando hay un char especial expresión regular (como .
, []
, o *
) No quiero que sea interpretado como tal. E incluso entonces grep -F
se prefiere la forma más portátil / estándar de fgrep
.