Забавный но досадный глюк

[SeZuka]

runewalsh влез в середине спора и не совсем понимаешь о чем спор.

Сколько можно. -_-" Там не только древняя письменность, но и специфические символы (математические или там игровые).
Кандзи не выдумываются, а заимствуются из китайского. "Very rarely-used" ни разу не значит "not used".

Мы говорим о кириллице, об иероглифах пускай китайцы и японцы спорят. Или вы пишите программы для обработки данных на китайском языке?

Предлагаешь вернуться к аду с 9000 кодировок? Зато в каждой отдельно взятой по байту на символ, чо.

Какие еще 9000 кодировок если речь только об английском тексте? Тут только одна кодировка ASCII.

[alexey38]

Итоги теста. Ни о каких порядках речи не идет, максимум в 6 раз для нескольких итераций теста, для одиночного теста в 3 раза (проявляется задержка на преобразовании кодировок).

Отлично, что кто-то от слов перешел к делу. В принципе Вы полностью подтвердили, то, что говорил я. То, что у Вас разница в 6 раз, то это серьезный критерий использования UTF16, вместо UTF8. Но 6 кратное превосходство получено на комплексном тесте. Если Вы сделаете тест, в котором будете индексироваться к символу с индексом 1000 или 10000, то получите разницу на порядки. С кодировкой UTF32 на уровне тестов сложнее, т.к. насколько я знаю нет стандартной библиотеки для работы с ней.

[debi12345]

Ни о каких порядках речи не идет, максимум в 6 раз для нескольких итераций теста, для одиночного теста в 3 раза

Во-во - ни много ми мало +200..+500%. Хотя обычно даже +100% считается огромным выигрышем Ясен перец, что с массовым (по умолчанию) внедрением UTF8 в манипуляции и отрисовку линуксоиды поторопились, ну а многие за ними последовали.

[SeZuka]

Если Вы сделаете тест, в котором будете индексироваться к символу с индексом 1000 или 10000, то получите разницу на порядки.

Не совсем понял о чем вы, но разве UTF8Copy(s, Pos, Count) не то делает? А если вам нужно найти адрес символа то для этого есть функция UTF8CharStart которую кстати и использует UTF8Copy.

[alexey38]

Не совсем понял о чем вы, но разве UTF8Copy(s, Pos, Count) не то делает? А если вам нужно найти адрес символа то для этого есть функция UTF8CharStart которую кстати и использует UTF8Copy.

Код: Выделить всё

    for i := 1 to Cnt.Value do begin
      utf16 := UnicodeUpperCase(utf16);
      utf16 := UnicodeLowerCase(utf16);
      j := Length(utf16);
      c := Copy(utf16, j div 4, j div 2);
      j := Pos(c, utf16);
    end;

В Вашем тесте измеряется скорость выполнения одновременно нескольких операций, и изменение регистра, и вычисление длинны, и копирование и поиск. Каждая операция для UTF8, UTF16 (UCS16) и UTF32 будет иметь разную длительность. Поэтому итоговый показатель - это среднее арифметическое из 5 разных операций. Но одна операция будет иметь отличие на 10%, а другая на 1000%, третья на 500%, и т.п. В сумме будет 300-600%.
В реальной программе может одних операций быть больше, а других меньше, поэтому одна реальная программа получит разность скорости в 100%, а другая в 1000%.

[runewalsh]

Мы говорим о кириллице, об иероглифах пускай китайцы и японцы спорят.

Не только иероглифы, вы можете захотеть использовать в специфичном приложении какую-нибудь доминошку (особенно если визуализация всё равно своя). Раньше такие размещали в последних символах ASCII как символ для частного пользования, но зачем это, когда есть стандартизированные доминошки.

В паскале?

В крестах же... Ненавязчивое предложение сменить инструмент, коль скоро всем недоволен и не хочешь городить велосипеды.

Уже достали со своими спорами, накидал небольшой тест для ленивых.

Уииии, ну наконец-то! ^_^
Есть одно "но". Вы привели результаты на случайных данных. Если взять реальные тексты, получим пикрелейтед — 1.4-1.8x. Слева "Божественная комедия" на русском, справа японский текст в рамках UCS-2. С текстами же в 7-bit ASCII разрыв и того меньше — 1.2-1.3x, что просто смешно.

[alexey38]

Ненавязчивое предложение сменить инструмент, коль скоро всем недоволен и не хочешь городить велосипеды.

Менять инструмент только ради того, что некоторые упертые голословно говорят, что UTF8 идеален.
Ладно бы не было лучшего решения, но оно есть. И даже этот синтетический текст, в котором множество разношерстных операций и на том видно кратную выгоду. Есть люди, которые не признают иных сортировок, кроме пузырька, есть те, кто не признает хэши (типа занимает лишнюю память и алгоритм хитромудрый), а есть такие же, кто не признает UTF32 и UTF16. Каждый волен для личных целей использовать что угодно. Но зачем пропагандировать другим плохие решения?

[debi12345]

то получите разницу на порядки.

Явный перегиб

[alexey38]

Явный перегиб

Расширил предложенный тест еще одной процедурой.
Имеем строку 10 000 символов, и в лоб подсчитываем в ней сколько пробелов. Прогоняем тест 100 раз.
Получаем результат:

Безымянный.png

А именно, на моем компе задача для UTF8 считается 48 сек, а с UTF16, UTF32 - 2 мс. Разница в 24 тыс. раз, т.е. на 4 порядка.
Задача немного искусственна, но старый наследуемый код, в виду быстроты подобных операций широко применялся. Для UTF8 можно написать функцию немного быстрее, но это будет функция под частный случай. Работа в UTF32 дает и скорость и гибкость реализации алгоритмов, и отсутствие глюков при работе с японскими строками.
Исходники:

utf8test_mod.rar

[SeZuka]

А именно, на моем компе задача для UTF8 считается 48 сек, а с UTF16, UTF32 - 2 мс. Разница в 24 тыс. раз, т.е. на 4 порядка.

Школьные задачки никогда не отличались быстротой работы. А в вашей реализации, UTF-8 изначально поставлен в невыгодное положение, для него используется алгоритм маляра Шлемиля, а для других индексированный доступ.
Переделал тест для UTF-8 на последовательный доступ, получил всего в 15 раз медленнее, но не на 4 порядка!

[alexey38]

Школьные задачки никогда не отличались быстротой работы. А в вашей реализации, UTF-8 изначально поставлен в невыгодное положение, для него используется алгоритм маляра Шлемиля, а для других индексированный доступ.
Переделал тест для UTF-8 на последовательный доступ, получил всего в 15 раз медленнее, но не на 4 порядка!

Так UTF8, в отличие от UTF32 и не поддерживает индексированный доступ. Именно это и есть главный недостаток строковых переменных с типом UTF8. Некоторые не верили, я показал. Не любой прикладной алгоритм использует последовательное обращение к строкам. Поэтому в общем случае падение быстродействия идет на порядки, в виду использования алгоритма маляра Шлемиля.
Переделав на последовательный доступ следующим образом:

Код: Выделить всё

      StartBytePos:=@utf8[1];
      for j:=1 to UTF8Length(utf8) do
      begin
        CharLen:=UTF8CharacterLength(StartBytePos);
        c8:=copy(utf8,StartBytePos-PChar(utf8)+1,CharLen);
        StartBytePos:=StartBytePos+CharLen;
        if c8=#32 then
          Inc(TestCount);
      end;


На моем компе разница по скорости получается в 30 раз для UTF16, в 32 раза для UTF32. 30 раз - это слишком много, это 3000%, чтобы такое не замечать.
Если пользоваться UTF8 из упрямства, то вместо лаконичного индексированного доступа:

Код: Выделить всё

        c32:=utf32[j];


Мы можем перестраивать алгоритмы к виду последовательного доступа, можем вводить дополнительные индексные массивы, прочие извращения. Но зачем? Если есть простое решение UTF32 (UTF16), то для чего используется сложное (UTF8)?

Для вывода на экран без разницы что использовать, слишком мало информации туда помещается. Но есть и другие задачи.

[absdjfh]

то для чего используется сложное (UTF8)

это кодировка для американцев она для них максимально удобна

[alexey38]

это кодировка для американцев она для них максимально удобна

Для американцев была удобна и ANSI (ASCII), у них все влазило в 7-битную кодировку. Когда возникли проблемы, кто-то придумал формальную отмазку UTF8, когда англоязычные алгоритмы тут же стали современными, они оказывается стали поддерживать не устаревшую ANSI, а супермодную и суперсовременную кодировку Unicode (UTF8). Уверен, что кто-то в США на такой формальной переделке заработал кучу бабосов, заказчик не вникает в нюансы, выделяет деньги, а на что они пошли он уже не знает. Тут также, как было с проблемой 2000, когда деньги одинаково брали те, кому требовалась переделка, и те, кому не требовалась переделка. Халява она очень приятна на вкус.

Америкосовские изобретатели стригли халявное бабло, и их мало волновало, что весь остальной мир поставлен раком. Для США это была идеальная ситуация, одна и та же задача (программа), на одинаковом компьютере в США выполняется в несколько раз быстрее, чем в Японии, Германии, Китае, России. Конкурентное преимущество на пустом месте. Чего еще в жизни надо? Вот судя по всему американцы выделили малую часть полученной сверхприбыли на пропаганду UTF8, как способ увеличить выхлоп (прибыль). А наши наивные думают, что в UTF8 есть какой-то смысл, кроме как нагнуть других и заработать бабосов.

[debi12345]

всего в 15 раз медленнее

Всего ?! Скромненько так...

это кодировка для американцев.она для них максимально удобна

Однако в "выни" они спокойно схавали UCS-2.

Если есть простое решение UTF32 (UTF16), то для чего используется сложное (UTF8)?

Думаю все-таки ради будущих алфавитов. Называя вещи своими именами - инопланетных алфавитов, чтобы легко было их интегрировать С другой стороны, к тому времени оперативка стнет вообще не вопросом - и UTF32 поереяет свой оснвоной недостаток - большой "размер" символа. Или остаться на UTF16 (c сурогтаными парами) перключаемой ключами компиляции с UCS-2. И писать параллелный код под UCS2,и под UTF16 - но последнюю до поры до времиени не активизировать по умолчанию. А как прилетят супостаты и деваться будут неекуда кроме как резко расширить место под алфавиты - массово персобрать софт под UTF16.

Добавлено спустя 3 минуты 49 секунд:
Спасение для UTF8 - аппаратная (на уровне CPU/GPU) акселерация строковых манипуляций, эдакие строковые MMX/SSE/шэйдеры

[alexey38]

С другой стороны, к тому времени оперативка стнет вообще не вопросом - и UTF32 поереяет свой оснвоной недостаток - большой "размер" символа.

У меня на компе (не самый медленный):

Безымянный1.png

Один оператор для строки из 100 млн. символов выполнялся 1 сек.

Код: Выделить всё

UTF8Length(utf8);

, а это всего 400 Мб в кодировке UTF32. На каком-нибудь ARM - это выполнялось бы целый час. Но даже для современных смартов 1 Гб ОЗУ - это минимум.
UTF8 просто неприменим для больших объемов текста в виду чрезвычайной медлительности. А при малых объемах у UTF32 нет недостатка в объеме занимаемой памяти. Какая разница, будет программа занимать 10 кБ или 20 кБ в ОЗУ?