> Геморрой, связанный с зоопарком ... В данном конкретном случае повышенный расход
> дискового пространства, траффика и тактов процессора - это сознательная и приемлемая
> плата за унификацию хранения текстов.Ну, вы уж слишком категоричны. Тред, всё-таки, в теме "Оптимизация и тюнинг", т. е. для тех, кому геморрой не "зоопарк", а "повышенный расход". В исходном сообщении не было никакого "данного конкретного случая". Речь не о полном отказе от UTF-8, а о принятии решения -- в каких случаях стоило бы посмотреть в сторону однобайтной кодировки. Понятно, что большинство программистов не будет заморачиваться поддержкой кучи кодировок внутри своих программ, но кто-то из них мог бы согласиться вставить опциональные конвертеры на входе и выходе. Без конвертеров тоже: если программа берёт на вход и выводит текст в UTF-8, вполне могут найтись люди, которые допишут к ней внешние паковщики с конвертерами прямо на своих системах (не геморрой же!), потому что паковать непосредственно UTF-8 системам сложнее. В частности, распаковка кириллического текста в KOI8-R с последующей конвертацией в UTF-8 (+ в обратном порядке) происходит в 1.6 раза быстрее, чем просто распаковка/запаковка того же текста в UTF-8 [1]. И не так уж это очевидно. По крайней мере, я раньше предполагал обратное. А с UTF-8, да, всё хорошо, если только она использована не для кириллицы.
С другой стороны, геморрой -- это тоже экспериментальный факт. Народ считает, что геморрой, значит так оно и есть.
Сноска:
[1] Сжатие -- xz без опций, конвертация -- iconv, текст -- в основном кириллица; если время загрузки процессов много меньше времени их работы.
