Bonjour, > > en meme temps, le jour ou t'as des fichiers texte de 250M, tu m'appelles ;) > Avoir des fichier de cette taille n'est pas si rare que ça, les > fichier de log peuvent facilement être de cette taille, par contre > l'operation qui consiste a trouver le 250 millième caractère n'a aucun > sens (du moins pas que je sache) !
Compter les caractères a un sens, en UTF-32 c'est immédiat, c'est la taille du fichier x 4, en utf-8 ça l'est beaucoup moins. Avancer/reculer de 100000 caractères peut très bien avoir un sens dans l'exploration et l'exploitation de longs textes (encyclopédies, compilations etc.). Pour les logs, tout dépend du format de log. Par exemple il est tout à fait possible de décider qu'une ligne de log fait toujours 80 caractères (qu'elle peut éventuellement se prolonger sur la ligne suivante si le 80 ième caractère est un \, amis du fortran bonsoir). Dans ce cas utf-8 produit un fichier binaire bordélique à souhait alors que utf-32 est un beau carré très facile à manier. > par contre trouver la x-ième ligne a en sens et du coup l'utf-8 est > bien plus rapide ! Sur des entrées-sorties en 32 bits (ou plus) avec des bus en 32 bits (ou plus) et des processeurs travaillant aussi en 32 bits ou plus, il n'est pas du tout évident que ce soit plus rapide, sauf si c'est codé par des américains (je blague). -- Au revoir, 02 99 64 31 77 Gilles Lamiral. France, Chavagne (35310) 06 20 79 76 06 _______________________________________________ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
