Класс в двух разных проектах обрабатывает данные за разное время

Профилирование? Примеры? Код? Libastral говорит, что дельфи и его производные - говно и падает с runtime error 186 по адресу 0x3f12ad15

Работа внутри цикла for деградирует. 10 прохождений в секунду на последних шагах цикла.

Что оно делает такое там внутри?

Парсит файл, закидывает в массив нужные части. Я думаю, может с какими либо лимитами связанно, тк сам проект увесист, может дополнительно что нибудь объявить нужно, что б пользоваться бОльшим объемом памяти. Ибо других идей нет. Там обычный вызов: MyClass.parse('data.txt'); Этот же вызов с этим же файлом в тестовом проекте на ура работает. Вижу явную разницу лишь в общем объеме потребляемой памяти и соответственно функционале вне данного класса и метода, который запускает метод parse.

Ну поставь лог с таймстампом после каждой строчки кода в подозрительном месте.

Под массив как память выделяешь? Как он у тебя растёт?

A:array of trec; При создании класса: Setlength(A,0);

Потом в parse() в цикле: setLength(A,length(A)+1);

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

while length(a) < required do setlength(a, length(a)*2)

В твоем случае required это индекс цикла и можно if вместо while. Может проблема и не в этом, но кошмарить аллокатор никакой пользы нет.

<= само собой

Код не покажешь? Если там массив, который растет на каждый чих - это значит там перевыделение и перекопирование каждый такой раз. В итоге замедление по экспоненте.

Массив растет как показал выше, сейчас переписываю со списками.

В итоге замедление должно было быть и в тестовом проекте, а его нет.

Про непрерывную область - это больше похоже на причину, об этой детали позабыл, буду проверять.

В тестовом у тебя более-менее «чистая» память, вот ничего и нету. На боевом там поди делается еще много всякого.

Забудь ты про эти несчастные списки, современные архитектуры их переваривают куда хуже, чем скопировать массив логн раз.

Лучше надо дёргать SetLength каждый раз, когда необходимо добавить только один элемент. В документации вообще написано, что каждый вызов SetLength неявно вызывает CopyArray.

Файл разного размера? Уверен, что парсер работает за линейное время от размера файла?

Файл один и тот же. Размер не меняется. Просто функционал написал в тестовом проекте, перенес в основной и оно вместо пары секунд на отработку - 1 мин 30 сек работает ( теперь ~ 1 мин 20 сек) Проверил, если сразу setLength(a,5000) сделать и потом вызывать, если нужны следующие 5000. Так же есть переменная с значением используемой длиной массива, прирост 5-8 секунд. Как я понимаю, setLength(a,sz+1) была не главной проблемой. С списками пока не дописал, ибо рабочий день окончен.

а если убрать работу с массивом и оставить только парсинг и создание записи?

С списками пока не дописал, ибо рабочий день окончен.

рабочий день!!

linux, lazarus, pascal...

нечасто встретишь такое в наше время

Нда, в си такой херни не бывает. В питоне, впрочем, тоже. Железо то разное, поди? Виртуалочки, NUMA, да рядом какое-нибудь дерьмецо крутится, да ресурсы откушивает? Профилировщика вам не завезли, я так понимаю?

Если у него лазарус, то там фрипаскаль внутри, который одним ключом может скомпиляться с gprof-ом. Тулкит-то один и тот же, чего там завозить. http://wiki.lazarus.freepascal.org/Profiling

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

Тогда действительно нужно посмотреть на флаги компиляции. Ну и на всякие вещи типа того, что в одном случае файл локально достаётся, а в другом - через какую-нибудь сеть.

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