Posté par dr_home .
En réponse au journal Unicode.
Évalué à 2.
Tu n'as toujours pas démontré que dans l'ensemble, ça a un impact significatif sur les perfs globales de la machine
Je sèche, homme admirable, as-tu une idée de comment mesurer une telle chose ? si je te disais démontre-moi qu'UTF-8 n'a aucun impact global, que pourrais-tu répondre à part que ça paraît globalement fluide ?
Or globalement, ça signifie en mode graphique et en console. En mode graphique, c'est impossible à quantifier pour des raisons déjà évoquées. Par exemple, si sur un même navigateur tu charges la même page en laissant un écran blanc jusqu'à ce que la page soit entièrement calculée ou en affichant progressivement d'abord les cadres les uns au dessous des autres, puis les cadres positionnés, puis les images, le deuxième rendu va te paraître aller plus vite que le premier.
Pour ce qui est de la console, c'est très différent car on n'est pas dans quelque chose de continu. On admet en général qu'on perd l'impression de fluidité aux alentours d'une demi-seconde de traitement. Donc, UTF-8 va avoir beaucoup plus d'impact sur le ressenti en console, d'autant que la machine est faible. Moi qui utilise la console intensivement (le nombre d'applications graphiques que j'utilise régulièrement se compte sur les doigts d'une main) et scripte énormément je le constate très fréquemment. C'est pourquoi si j'avais une petite/vieille machine, j'étudierais sérieusement l'option 8bits pour en tirer le meilleur parti.
Ton dernier commentaire: 1323 octets en Latin-9, 1367 octets en UTF8. "Perte" de 3%. Quelle misère!
Sur un disque de moins d1Go où tu dois précautionneusement arbitrer entre le système et les données, ça peut être non négligeable. Et puis je pourrais faire comme toi: démontre-moi que mon commentaire est représentatif de ce qu'on écrit globalement en français. Peut-être que ce n'est pas 3 mais 10 ou 15% de pénalité dans la réalité !
C'est exactement le genre d'optimisation comme ceux qui compilent pour un CPU super-précis par rapport au défaut "c'est pour optimiser, c'est démontré", juste que c'est pas du tout rentable et il reste juste quelques rares masochistes à le faire, pareil pour garder Latin-9 : tout va bien, jusqu'au jour où tu devras partager le fichier avec un gus qui n'a pas cette locale (si si, ça arrive, on vit dans un monde qui s'afranchit des frontières), alors qu'avoir UTF-8 simplifie grandement la vie au prix d'un pauvre 3% de plus en espace disque et à peine plus de CPU. Heureusement qu'il y en a qui regardent l’intérêt réel, maintenant à a toutes nos distros en UTF-8.
Sauf que dans la vie réelle, ma glibc me permet de décoder/encoder les fichiers comme je veux (fais un iconv -l, pour t'en convaincre) et donc de partager avec n'importe qui.
Sauf que dans la vie réelle, j'en n'aurai même pas besoin parce que vim me permet d'éditer avec l'encodage de mon choix.
Sauf que dans la vie réelle, la seule langue que je baragouine à part le Français c'est l'Anglais, donc afficher le Cyrillique, les Kanjis ou l'Arabe, ça ne m'avance pas beaucoup par rapport à une pâtée 8bits.
Sauf que dans la vie réelle, les distros pour vieilles machines balancent les locales à part POSIX/en_US pour gagner de la place.
Sauf que dans la vie réelle, j'ai passé des années en Latin9 sans en souffrir plus que ça.
Est-ce qu'au moins, dans la vie réelle, tu te rends compte que tu en es à prétendre connaître mieux que moi mes besoins et l'usage que j'ai de ma machine ?
[^] # Re: Utilité
Posté par dr_home . En réponse au journal Unicode. Évalué à 2.
Je sèche, homme admirable, as-tu une idée de comment mesurer une telle chose ? si je te disais démontre-moi qu'UTF-8 n'a aucun impact global, que pourrais-tu répondre à part que ça paraît globalement fluide ?
Or globalement, ça signifie en mode graphique et en console. En mode graphique, c'est impossible à quantifier pour des raisons déjà évoquées. Par exemple, si sur un même navigateur tu charges la même page en laissant un écran blanc jusqu'à ce que la page soit entièrement calculée ou en affichant progressivement d'abord les cadres les uns au dessous des autres, puis les cadres positionnés, puis les images, le deuxième rendu va te paraître aller plus vite que le premier.
Pour ce qui est de la console, c'est très différent car on n'est pas dans quelque chose de continu. On admet en général qu'on perd l'impression de fluidité aux alentours d'une demi-seconde de traitement. Donc, UTF-8 va avoir beaucoup plus d'impact sur le ressenti en console, d'autant que la machine est faible. Moi qui utilise la console intensivement (le nombre d'applications graphiques que j'utilise régulièrement se compte sur les doigts d'une main) et scripte énormément je le constate très fréquemment. C'est pourquoi si j'avais une petite/vieille machine, j'étudierais sérieusement l'option 8bits pour en tirer le meilleur parti.
Sur un disque de moins d1Go où tu dois précautionneusement arbitrer entre le système et les données, ça peut être non négligeable. Et puis je pourrais faire comme toi: démontre-moi que mon commentaire est représentatif de ce qu'on écrit globalement en français. Peut-être que ce n'est pas 3 mais 10 ou 15% de pénalité dans la réalité !
Sauf que dans la vie réelle, ma glibc me permet de décoder/encoder les fichiers comme je veux (fais un
iconv -l, pour t'en convaincre) et donc de partager avec n'importe qui.Sauf que dans la vie réelle, j'en n'aurai même pas besoin parce que vim me permet d'éditer avec l'encodage de mon choix.
Sauf que dans la vie réelle, la seule langue que je baragouine à part le Français c'est l'Anglais, donc afficher le Cyrillique, les Kanjis ou l'Arabe, ça ne m'avance pas beaucoup par rapport à une pâtée 8bits.
Sauf que dans la vie réelle, les distros pour vieilles machines balancent les locales à part POSIX/en_US pour gagner de la place.
Sauf que dans la vie réelle, j'ai passé des années en Latin9 sans en souffrir plus que ça.
Est-ce qu'au moins, dans la vie réelle, tu te rends compte que tu en es à prétendre connaître mieux que moi mes besoins et l'usage que j'ai de ma machine ?