Это ты уже разводишь "демагогию".
В реальной жизни все может быть.
А вообще-то нужно было проверить от 1-го символа до 255-и.
Но и так ясно, что поиск SubStr разной длины при применении NewPosEx занимает почти одно и тоже время (разница мизер ), чего не скажешь о других методах.
Так что я остаюсь при своем мнении. Извини.
Надеюсь, что и Dilma понравится именно Asm-вариант

Насчет а какой код не самопальный ? Все коды самопальные.
------------ Дoбавленo в 17.31:
Да и помоему ASM - пофиг кодировки.

Tadd, а у меня asm код показывает отвратительный пезультат. Не забывай и о разных машинах -- у тебя AMD, а у меня Intel



Еще вопросы есть
------------ Дoбавленo в 17.44:
Увеличение быстродействия кода asm ощущается только на длине строки до 2-х символов, дальше он идет в отставание. Зафиг такой ущербный код, что ты будешь делать -- искать стабильно один символ, или, все же, строку, минимум, из двух символов, где скорость кодов соизмерима. Средняя скорость всегда будет выше при разной длине поисковых строк, это и ежу ясно, вот только тебе, почему-то, совсем это не ясно

безусловно


а при чем тут это?

PS: между словом - по хорошему asm версию PosEx можно еще больше ускорить, если вставить отдельные реализации поискового алгоритма при длине искомой строки в 1, 2, 4 и 8 символов. Так если на 64х разрядной ос искать вхождение 8ми символьной подстроки, то можно ограничиться всего одним циклом со всего одной командой сравнения двух 64х битных операндов.

И почему так категорично
Почему именно безусловно Примененный asm алгоритм не является оптимальным, так и написано там, откуда я его взял. Это видно и по тестовым результатам. Или у вас свои тестовые предпочтения

Да притом, что некоторые процессорные операции выпоняются по-разному на разных машинах с разными процессорами и разной архитектурой, или это новость По результату тестов это прекрасно видно

С оптимизауией под кратные строки я согласен, это даст прирост производительности

Может стоит в компонент Project свойство добавить, которое будет условной трансляцией выбирать метод поиска?

ну насчет производительности, помоему, лишняя цель.
"Чистим" функцию. Оставляем только, например:

и получаем на длинной строке время ~220 мс.

Это ни о чем не говорит ?

И что ты тут почистил, я в упор не вижу

С чего получаем, не вижу кода, который дает такой результат

именно кода нет, а время есть.
Вот эта строчка требует 220 мс.
А оставшиеся 100- 130 мс (от общего времени) тратятся на работу функции.

nesco, у меня нет текстового файла под 100 Мб для проверки ваших опусов, но есть HiAsm code_17911.txt

Его тут выкладывали, он всего 6 Mb весит упакованный
Леонид, ну вот скажи, к чему ты это выложил, ну никто и не сомневался, что ты знаешь HiAsm, вопрос-то совсем в другом был

Вот не сыпал бы ты соль на рану, и так тошно, столько времени угрохал впустую, хоть, и в отпуске

да, новость. Даже две - не знал, что команды процессора могут исполняться на разных архитектурах... всегда полагал, что архитектура как раз и определяет набор поддерживаемых команд, а не наоборот. Не знал так же и то, что производители плюют на даташиты по командам той архитектуры, под которую они делают проц, где как раз и написано, что команда должна делать и за сколько тактов
Ну и к слову - любой яву код компилируется в те же самые команды процессора, с которыми вроде ни у amd, ни у intel описанных выше проблем нет. Или в другие все же?

Прикол не в командах, а в разных подходах к исполнению этих команд внутри проца. AMD всегда выполнял регистровые операции быстрее Intel, за счет особенности архитектуры. А в даташитах всегда указывают нижний предел скорости выполнения инструкции, и никто не пойдет на то, чтобы ограничивать скорость, если удалось ее поднять за счет разных ухищрений, в том числе, и из-за особенности архитектуры

nesco, время "ухлопано" совсем не впустую, драгоценный олыт для себя и для всех нас, спасибо!

Спора нет - иметь HiAsm - дело хорошее.

Леонид, вопрос:
Зачем нужны окна задания размеров слов в Вашем опусе (от и до)

Tad, для похожести текста на литературное произведение