SeZuka писал(а):Школьные задачки никогда не отличались быстротой работы. А в вашей реализации, 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 из упрямства, то вместо лаконичного индексированного доступа:
Мы можем перестраивать алгоритмы к виду последовательного доступа, можем вводить дополнительные индексные массивы, прочие извращения. Но зачем? Если есть простое решение UTF32 (UTF16), то для чего используется сложное (UTF8)?
Для вывода на экран без разницы что использовать, слишком мало информации туда помещается. Но есть и другие задачи.
Ясен перец, что с массовым (по умолчанию) внедрением UTF8 в манипуляции и отрисовку линуксоиды поторопились, ну а многие за ними последовали.