Поставил твою строку, убрал ";" - орет. Что там у тебя не знаю. (Не подтверждается )

Для 10 000 строк
Минимальное среднее время, после 10-ти нажатий, 2.55 сек.
Для StringTable - 3.0 сек
Для StringTableMT - 5.8 сек

А для 100 000 строк:
StringTable - 30.0 сек
StringTableMT - не дождался ( минут пять ждал. Надоело.) - черепаха, она и в Африке черепаха.
MTStrTbl - 25 сек

Сохранить забыл, вот что

Действительно, орет.

Получается около 25 % прироста. Весьма неплохо.

И больше, чем в два раза в сравнении со StringTableMT

по сравнению с чем ?
------------ Дoбавленo в 14.03:
Мой предыдущий пост посмотри еще раз

MTStrTbl в сравнении со стандартной, в последнем случае (25 против 30), получается 17%

Кто-то из нас точно не бухгалтер
Поделись своей формулой

Вот моя:
Если 25 и 30, то выигрыш 5 секунд
5 сек по отношению к 30 = (5/30)*100= ~17%

Tad,

Я от 100 отнял 87 (25/30) и получил 27, бывает (отрывают меня в отпуске по-мелочам)

Другое прикольно, как Dilma получил 25%, мне непонятно, я там чего только не выкидывал, но такого результата получить не удалось

С кодами Dilma у меня результат 30 - 28.4 = 1.6 сек разницы. Только что проверил повторно.
Может он считал от результатов исходных ( до переделки) кодов ?

Tad, осталось последнее -- перевести веcь этот метод на asm, тогда еще можно выдавить быстродействие

А зачем лишняя головная боль?
Мы в тесте крутили по 10 000 и 100 000 строк. В реальности такого, при умном програмирующем, никогда не будет.
А с одним словом "nesco" разница всего 28-24=4сек.

Ха, там 5 сек, а тут 4 сек, ох и большое различие. Но я тебе про то и говорил, что время парсирования зависит от длины общей строки
------------ Дoбавленo в 15.46:

А в чем проблема, но когда-то учиться надо и переходить на asm. Ради интереса можно попробовать, если получится, то посмотреть, каков выигрыш

кто это сказал? От того, что KOL так написан данный подход не делается стандартом де факто. Программирование под GUI на Assembler это трата своего времени и чужого без гарантии получения выигрыша от его использования.

ну и наконец это совершенно бессмыслено в данном случае уже потому, что узким местом является вовсе не код метода, а обращение к таблице через сообщения Windows.

Мда... Ну, тогда -- пес с ним, с asm

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

в итоге после всех этих операций конечный код на ассемблере может не совпадать с тем, что написал программер за счет проделывания за него той работы, которую программист в силу своей человеческой природы не мог или не захотел делать. Т.е. код с яву фактически на 99% близок к машинному. Однако когда неискошенный в этом деле программист садиться за ручное написание этого идела путем ассемблерных вставок, то почти наверняка у него получится хрень, которая будет работать медленнее исходного варианта или отъедать больше машинных ресурсов. Соответственно чем сложнее целевая архитектура(x86 - сегодня самая простая наверно), тем хуже ассемблерный код не профессионального программиста, пишущего под нее.

PS: конечно в случае с FPC это все может может не очень соответствовать дествительности...