Posté par dr_home .
En réponse au journal Unicode.
Évalué à 2.
Oui. Comme la mise en forme. Supprimons tout!
Comme la conclusion de mon message, tu veux dire (on n'a pas tous des super-machines de la mort) ?
Je sais pas ce que tu fais de tes scripts, mais au pif je dirai que 99% des scripts se contrefoutent de la locale.
Prends les scripts qui font du traitement de chaînes (ce qui est un peu la base du Shell) :
$ seq 10000 >/tmp/out
$ time grep 7 /tmp/out >/dev/null
real 0m3.196s
user 0m3.190s
sys 0m0.002s
$ time LANG=C grep 7 /tmp/out >/dev/null
real 0m0.003s
user 0m0.001s
sys 0m0.001s
$ time sed /7/p -n /tmp/out >/dev/null
real 0m0.015s
user 0m0.011s
sys 0m0.003s
$ time LANG=C sed /7/p -n /tmp/out >/dev/null
real 0m0.010s
user 0m0.008s
sys 0m0.001s`
$ time awk '{print length(0ドル)}' /tmp/out >/dev/null
real 0m0.020s
user 0m0.018s
sys 0m0.002s
$ time LANG=C awk '{print length(0ドル)}' /tmp/out >/dev/null
real 0m0.012s
user 0m0.008s
sys 0m0.002s
Tous les utilitaires sont plus ou moins ralentis. Et là dans ces tests, je suis mignon parce que ce sont de toutes petites chaînes, mais plus les chaînes traitées vont être longues (genre quand tu traites un fichier comme une seule chaîne), plus ça va se sentir (il m'arrive de compter la différence en minutes lorsque ça se couple avec de la recherche intensive de fichiers). Or, on a rarement besoin de s'appuyer sur une représentation correcte des caractères qui ne sont pas dans l'ASCII.
Note également que je ne suis pas le seul à mentionner le coût d'UTF-8, Perl, dont c'est pourtant la grande spécialité, le documente même dans perlunicode :
Speed
Some functions are slower when working on UTF-8 encoded strings than on byte encoded strings. All
functions that need to hop over characters such as length(), substr() or index(), or matching regular
expressions can work much faster when the underlying data are byte-encoded.
In Perl 5.8.0 the slowness was often quite spectacular; in Perl 5.8.1 a caching scheme was introduced
which will hopefully make the slowness somewhat less spectacular, at least for some operations. In
general, operations with UTF-8 encoded strings are still slower. As an example, the Unicode properties
(character classes) like "\p{Nd}" are known to be quite a bit slower (5-20 times) than their simpler
counterparts like "\d" (then again, there 268 Unicode characters matching "Nd" compared with the 10
ASCII characters matching "d").
[^] # Re: Utilité
Posté par dr_home . En réponse au journal Unicode. Évalué à 2.
Comme la conclusion de mon message, tu veux dire (on n'a pas tous des super-machines de la mort) ?
Prends les scripts qui font du traitement de chaînes (ce qui est un peu la base du Shell) :
Tous les utilitaires sont plus ou moins ralentis. Et là dans ces tests, je suis mignon parce que ce sont de toutes petites chaînes, mais plus les chaînes traitées vont être longues (genre quand tu traites un fichier comme une seule chaîne), plus ça va se sentir (il m'arrive de compter la différence en minutes lorsque ça se couple avec de la recherche intensive de fichiers). Or, on a rarement besoin de s'appuyer sur une représentation correcte des caractères qui ne sont pas dans l'ASCII.
Note également que je ne suis pas le seul à mentionner le coût d'UTF-8, Perl, dont c'est pourtant la grande spécialité, le documente même dans
perlunicode: