Mike Haertel oublie de préciser que jusqu'en 2010 GNU grep avait des performances atroces en UTF-8, ce qui n'est pas glorieux.
Par exemple grep 2.5.4 met 42 secondes sur un Core 2 Duo 2Ghz à exécuter:
$ time LC_ALL=fr_FR.UTF-8 grep . a.txt > /dev/null
real 0m42.440s
user 0m42.432s
sys 0m0.001s
Où le fichier a.txt est un fichier de 40000 lignes (80 Ko) de 'a'.
Alors qu'en locale C, 8 millisecondes suffisent
$ time LC_ALL=C grep . a.txt > /dev/null
real 0m0.008s
user 0m0.007s
sys 0m0.000s
C'était tellement lent que j'ai découvert le "bogue" sur un traitement d'un fichier contenant des noms de fichiers à déplacer d'un répertoire à un autre, parce que c'était trop lent... Le facteur limitant n'étant pas le déplacement des fichiers mais quelques opérations grep!
Heureusement ça a été corrigé à la 2.7 sortie en septembre 2010.
Le bogue
[^] # Re: capabilities
Posté par NanoTech . En réponse à la dépêche FreeBSD 9.0 est disponible. Évalué à 8.
Mike Haertel oublie de préciser que jusqu'en 2010 GNU grep avait des performances atroces en UTF-8, ce qui n'est pas glorieux.
Par exemple grep 2.5.4 met 42 secondes sur un Core 2 Duo 2Ghz à exécuter:
$ time LC_ALL=fr_FR.UTF-8 grep . a.txt > /dev/null
real 0m42.440s
user 0m42.432s
sys 0m0.001s
Où le fichier a.txt est un fichier de 40000 lignes (80 Ko) de 'a'.
Alors qu'en locale C, 8 millisecondes suffisent
$ time LC_ALL=C grep . a.txt > /dev/null
real 0m0.008s
user 0m0.007s
sys 0m0.000s
C'était tellement lent que j'ai découvert le "bogue" sur un traitement d'un fichier contenant des noms de fichiers à déplacer d'un répertoire à un autre, parce que c'était trop lent... Le facteur limitant n'étant pas le déplacement des fichiers mais quelques opérations grep!
Heureusement ça a été corrigé à la 2.7 sortie en septembre 2010.
Le bogue
Références
http://git.savannah.gnu.org/gitweb/?p=grep.git;a=commitdiff;h=7a0ad00f634237b753572378289d76fa8f1c5942
http://rg03.wordpress.com/2009/09/09/gnu-grep-is-slow-on-utf-8/