Neo, рассуждая по-диалетантски, если без потоков всё работает, но не успевает, то надо смотреть загрузку процессора
------------ Дoбавленo в 16.52:
в этот момент -- близко к 70--100% ничего не поможет, кроме изменения и оптимизации самой обработки,
------------ Дoбавленo в 16.53:
если загрузка 25% надо думать об опять же (изменения и оптимизации) и о расчленении вычмслений с помощью потоков

Новая вводная: оказывается если добавлять значения через таймер - все ок. А если руками - обязательно где-то потеря.
code_24895.txt
------------ Дoбавленo в 16.54:
Проверил: загрузка как была 5 процентов - так и осталась пока программа тупила и сравнивала строки.
------------ Дoбавленo в 16.56:
Как это так, что таймер по-братски программе скармливает данные и она довольна, а данные от руки она брезгует?
------------ Дoбавленo в 16.57:
При этом таймер быстрее отдает данные, чем вручную.

Neo, категорически не рекомендуется работать с данными, к которым может получить одновременный доступ другой поток программы. Помимо Ваших глюков можно "поймать" фатальную ошибку и аварийное завершение приложения. А с таймером (временно?) работает потому, что таймер тоже порождает независимые потоки, у Вас был конфликт основного потока приложения с порождёнными Вашими Thread.

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

1nd1g0, давно бы пояснили, (Вот так, из-за недостаточных знаний и рождаются мифы )
(Зато найден исток расстрельной статьи )

Ага, вот только событие WM_TIMER обрабатывается в основной очереди, а не как попало у Thread на Exec, те так же, как в Tread на onSyncExec

Оцените, пожалуйста, данное творение. То ли на мена спустилось просвещение и всю эту паутину я заменил одним таймером, то ли эта схема жить не будет?
code_24896.txt
------------ Дoбавленo в 17.51:
Или если таймер создает отдельные потоки то эта схема тоже от лукавого?
------------ Дoбавленo в 17.57:
Или даже может таймеру поставить задержку в 1-5, а не 20? Не чревато? Ведь стек игнорирует взятие с пустого.
------------ Дoбавленo в 17.58:
тихо сам с собою я веду беседу...

Neo, из потока, порождённого таймером, управлять родительским таймером не рекомендуется. Как правильно дополнил nesco, таймер синхронизирован с основным потоком. Похожий эффект даёт вторая точка события, выходящая из Thread. Кажется, Леонид уже предлагал Вам воспользоваться ею.

Да, синхронизированным событием пользовался, но рузультата, как писал, плачевен при использовании, как было. Теперь вроде бы и можно его пользовать, но нужно ли? Есть смысл заменять таймер потоком?
------------ Дoбавленo в 18.20:
1nd1g0, пожалуйста, объясните почему относится к схеме? Там же таймер включен независимо и молотит себе отдельно, никаким другим таймером не управляясь.

Neo, кстати о птичках: У ТАЙМЕРА ШАГ 1/64 сек, и какие бы Вы циферки не выставляли, интервал будет минимум 15.625 мсек, 31.25 мсек .... кратно 1/64 сек

Neo, созданный в другом потоке таймер, начинает работать под управлением основного потока. Прикинь, что получается, когда в другой поток лезет основной поток отрабатывать чужой (как бы) таймер
------------ Дoбавленo в 18.25:
Леонид, остерегайся окультных выводов, твои утверждения верны для загруженных одноядровых систем. Современные процы способны отрабатывать очереди событий, включая графические, на порядки быстрее, им в этом еще и граф ускорители помогают

nesco, нарисовал бы схему, да интернет+форум не позволяет выложить. И на ХР 2,4 ГГц (2 ядра) и на Win7 3,5 ГГц (4 ядра)

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

одинаковый для HiAsm результат: выставляю на таймере "0" и на счётчик -- за 1 секунду ровнёхонько 64 события,
------------ Дoбавленo в 18.33:
выставляю 28 -- 32 события в секунду

Вы таймер останавливаете потоком, который он же и породил.