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

[bormant]

вместо "p := @utf8[1]" должно быть "p := @utf8[i]"?

Нет.
на первой итерации p указывает на первый символ строки. После p := StrPos(p, @c8[1]), p указывает на найденное вхождение либо, если p = nil, то ничего не нашлось, выходим. Если что-то нашлось, сдвигаем указатель (у меня 1 -- демонстрация самосинхронизации UTF-8, есть смысл сдвигать на длину искомой строки, но для конкретно этого случая inc(p, Length(c8)) скорее всего в общем итоге будет медленнее, чем простой инкремент. Для поиска длинного фрагмента -- наоборот). Продолжаем искать следующее вхождение.
Например:

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

    .....Я.....Я....
1: p^
2:      p^ -- нашли
3:       p^ -- сдвинули и продолжили
4:            p^ -- нашли
5:             p^ -- сдвинули и продолжили
6: p=nil -- больше вхождений нет


А внешний цикл i := 1 to TRIES do -- просто несколько прогонов подряд для кратного увеличения времени работы, чтобы снизить влияние случайных неравномерностей, например, от загрузки машины чем-то ещё в многозадачной системе.

[hovadur]

bormant у меня в linux

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

UTF-8: 86 ticks
UTF-16: 246 ticks
UTF-32: 245 ticks


Добавлено спустя 3 минуты 7 секунд:

на первой итерации p указывает на первый символ строки

Понял.

[bormant]

hovadur,
чем меньше вхождений искомого символа, тем эффективнее будет вариант с UTF-8 (исключительно из-за эффективности реализации поиска подстроки по сравнению с генерируемым fpc кодом перебора символов массива) и наоборот.

[hovadur]

ну что, делаем вывод, что UTF-8 все-таки в linux лучше, чем UTF-16? А в windows UTF-16 лучше UTF-8?

Добавлено спустя 1 минуту 53 секунды:
что-то здесь не то, ведь не может быть так просто

[bormant]

сделайте "fpc -al test.pas" и посмотрите, что реально генерируется для каждого из случаев. В конце концов, чудес не бывает.

Добавлено спустя 5 минут 37 секунд:
А при сборке с оптимизацией, скажем "fpc -O3", варианты UTF-16 и UTF-32 становятся значительно эффективнее, попробуйте.

[alexey38]

После того, как были проведены дополнительные тесты, то я бы предложил подвести выводы (про техническую сторону вопроса).
1. Унаследованные алгоритмы (написанные кем-то лет 10, 20 назад) чрезвычайной сложно переписать под строки UTF8. Если проект сложный, то дешевле будет купить самолет.
2. Если пишется новый код для строк UTF8, то для получения приемлемого быстродействия (медленнее, но всего только в несколько раз) нужно писать индивидуальный код, нужно над каждой строковой операцией задуматься, подумать не предвидится ли корректировка в задаче. В любом случае длина быстрого кода на много сложнее, чем код под UnicodeString. Без комментариев в будущем будет непонятно, что хотели написать, особенно, если код чужой. В результате новый код для строк UTF8 будет по себестоимости (в человекочасах) будет значительно дороже, да и повышается требования к железу, для внедрения задачи.
3. Итого, учитывая п.1 и п.2. я бы сказал, что строки UTF8 хороши для очень богатых людей, которые деньги гребут лопатой. Для них легко будет довложить в проект лишний миллион баксов. Я лично богатых встречал, но они очень тщательно считают деньги.
4. Строки UnicodeString не обладают недостатками п.1-3, но есть риск нарваться на 4-х байтовые литералы. Все простые и быстрые алгоритмы это не учитывают, и могут не корректно работать (смотря как реализовано).
5. Строки UTF32String не разработаны на уровне библиотеки, хотя они не обладают недостатками п.1-4. На тестах, на моем компе они работали быстрее всех, т.е. быстрее UnicodeString, возможно, что для современных процов 32-битные операции быстрее, чем 16 битные. Но в виду отсутствия библиотеки тема пока висит в воздухе. Не хотелось бы писать личные библиотеки для таких общих вещей, как строки. Повышенная потребность в памяти может быть актуальна на задачах для смартфонов, но для современных компов ОЗУ велико, и задачи обработки Гб-строк упираются не в ОЗУ, а в быстродействие.
6. При хранении на диске формат UTF8 всем хорош, за исключением ситуации (без ВОМ), когда файлы исходных данных (настроек) могут быть заданы не в той кодировке, в какой ты ожидаешь. Если юзер - теточка 50 лет, то такая мелочь выливается в необходимость участия систадмина, что удорожает сопровождение проекта. Хотя некоторые сложности бывают и у сисадминов, когда нужно настроить прогу под линухом, и не знаешь в какой кодировке должен быть файл конфигурации (не все проги идут из репозитария, и не все они свежие), но сисадмин хотя бы понимает о чем речь. А теточка просто требует в соответствии с договором приезда специалиста, и получаются просто прямые убытки.

Конечно не все программисты сталкиваются со всеми проблемами. Кто-то с ними может не сталкиваться в виду специфики его задач. Но практика больших проектов показывает на наличие серьезных проблем. И это не только теория и предпочтения. Это большие деньги, и если встать на неверный путь, то тебя ждет разорение. А при правильном пути ты зарабатываешь хорошие деньги.

[debi12345]

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

Добавлено спустя 12 минут 56 секунд:
Искать нужно по очереди все символы #32..#65535, и считать за результат среднее значение.

[bormant]

зря занимаетесь оптимизациями алгоритма поиска конкретных букв

Это не оптимизации, это применение одного из базовых свойств UTF-8 -- для поиска подпоследовательности посимвольный разбор строки не требуется. А кроме того, это иллюстрация свойств автосинхронизации и той самой совместимости -- StrPos() или strstr() сохраняют работоспособность в новых условиях.

Добавлено спустя 4 минуты 2 секунды:

Искать нужно по очереди все символы #32..#65535, и считать за результат среднее значение.

Никто не спорит, что в отдельных сценариях использования UTF-8 будет по производительности существенно проигрывать другим вариантам на их поле. В конце концов, и вместо "inc(a, 5)" можно "for i:=1 to 5 do inc(a)" писать, вот только никто этого обычно не делает.

А свою задачу -- обеспечение совместимости -- UTF-8 выполняет, типичный сценарий: загрузка из файла в UTF-8, конвертация во внутреннее представление, обработка, запись в файл в UTF-8.

[debi12345]

для поиска подпоследовательности посимвольный разбор строки не требуется.

А если другая задача ? Под нее тоже "костыль" писать ? И так до бесконечности Так что давайте проверять штатные средства.

Добавлено спустя 4 минуты 3 секунды:

конвертация во внутреннее представление

То бишь во внутренний быстродействующий ЮНИКОД. Это же здорово ! Только почему-то отергнуто нашим сообществом.

[alexs]

alexey38
Ты всё хорошо говоришь, всё правильно.
НО!
На самом деле показанные тобой примеры - это ОЧЕНЬ частный случай. В нормальных продакшен системах оно так сильно не используется.
Я переношу код, который был написал 10-15 лет назад (ещё на D5) на лазарь. НЕТ ТАКИХ ПРОБЛЕМ. Изначально код был написан правильно (без хаков) и сейчас при конвертации нет проблем со строками.
А узкозаточеные функции на обработку строк - если хочешь повышения производительности - ты вседа будешь оптимизировать код. И это вообщето никак не связано с кодировкой.
PS
А UTF8 - это правильный путь.

[debi12345]

А UTF8 - это правильный путь.

LAZARUS & fpGUI only, AFAIK

[alexey38]

На самом деле показанные тобой примеры - это ОЧЕНЬ частный случай. В нормальных продакшен системах оно так сильно не используется.
Я переношу код, который был написал 10-15 лет назад (ещё на D5) на лазарь. НЕТ ТАКИХ ПРОБЛЕМ. Изначально код был написан правильно (без хаков) и сейчас при конвертации нет проблем со строками.
А узкозаточеные функции на обработку строк - если хочешь повышения производительности - ты вседа будешь оптимизировать код. И это вообщето никак не связано с кодировкой.

Вам удалось провести анализ всех существующих в мире программ на паскале? Если нет, то на каком основании Вы делаете вывод о том, что указанные мною проблемы - это частный случай?

Я думаю, что именно у Вас частный случай, когда Вам повезло и наследованный код изначально оказался очень хорошим. По моему личному опыту, а также на основании литературы можно сделать вывод о том, что примерно 90% программистов в мире пишут плохой код. Вы лично можете писать очень качественный код, но наследованный код - это код, который не Вы писали. Вам дают чужой код (корявый, но работоспособный), дают деньги, и просят что-то переделать. Если переписать все, то не хватит ни денег, ни времени. Часто нет даже нормального описания того, чего и как конкретно чужая программа решала задачу. Но кое что переделать надо. С UTF8 вообще не вариант, и задачу не выполнишь, и денег не заработаешь, всем плохо.

Посмотрев приведенные здесь примеры оптимального кода для UTF8 можно сделать однозначный вывод, что как строковый тип UTF8String - это какой-то идеологический костыль. Получается и громоздкий и неочевидный код. Конечно каждый в праве для себя решать, что ему использовать. Но я для себя только подтвердил, ранее сформированную позицию, что UTF8 - тупик. С ним и сам денег не заработаешь, и все нормальные программисты разбегутся, ведь за малые деньги никто не будет работать, ведь все же хотят быстро заработать и купить машины, квартиры, и т.п. У платежеспособных заказчиков не такие уж и огромные бюджеты. и нормально заработать можно, только если не делать ни одного лишнего движения. С UTF8String таких движений будет масса, вместо 2 дней, разработка займет неделю (вместо 1 месяца, будет 3 месяца), а это значит, что 70% заказов станет нерентабельными.

[hovadur]

у кого-нибудь повторяется, что на linux, предложенная bormant алгоритм для UTF-8, быстрее чем UTF-16?

[Brainenjii]

мне часто надо находить подстроку, но ни разу не потребовался доступ к символу по индексу. Ни разу. За все время работы. На всех языках, коими пользовался. Тем паче, что в общем случае эта задача нетривиальна для всех UTF-x, из-за всевозможных ударений, умляутов и прочего.
Для посимволного доступа UTF8 сливает для UTF-16 или UTF-32. Для передачи, например, JSON по сети - выигрывает у UTF-16 и UTF-32. Серебряной пули нет и в кодировках.
Так что если Вы пытаетесь доказать, что UTF8 не годится для задач посимвольного доступа - то Вы правы и с Вами все согласны, к чему флуд на 15 страниц?
Если Вы пытаетесь доказать, что использование UTF8 - ошибка, весь мир идиоты и необходимо срочно переходить на UTF16/32 - вы... Сами подберите нужное определение ^_^

[debi12345]

это какой-то идеологический костыль

Да не костыль, а неправильная вероятностная оценка, или тщетная надежда на "умощняющаяся аппаратура нивелирует все тормоза". Почему тщетная ? Потому что наблюдается вспеск маломощной портабельной апапартуры - и оптимизация теперь опять стала "маст би". Дальше аппаратура будет еще дальше миниатюризовываться, требования к оптимизации софта тоже расти, ну и.. ясно.
Кодировка быстра если порядка 99+ % обращений в ней возможны по индексам литер - то есть без дополнительных телодвижений. В случае ЮЦС2 сейчас такая вероятность достигнута для земных алфавитов, в случае ЮТФ16 и ЮТФ32 достигнута и для будущих инопланетных алфавитов. А вот в случае ЮТФ8, беря в учет население Китая и славянских стран, а также спецлитеры немецкого, французского и некоторых других латинских языков,.. - думаю совсем другие проценты попадания "мимо литер" уже сейчас. То есть один краеугольных принципов оптимизации "тяжелые вычисления - максимум один раз на входе и один раз на выходе, весь остальной рабочий цикл - легкие вычисления" грубо нарушен уже сейчас (без инопланетян и чокнутых алфавитных националистов), дальше будет только хуже.

Добавлено спустя 9 минут 16 секунд:

Если Вы пытаетесь доказать, что использование UTF8 - ошибка, весь мир идиоты

??? Мыже не о хранении файлов и сетевых трансферах базарим (ту и ежу понятно, что для этих дел ЮТФ8 практически идеальна), а о мапипуляциях с базовым строковым типом : )
"Весь мир", кроме ЛАЗАРУС энд фпГУЙ - сидит на базовом типе ЮТФ16.