Работа с памятью: KOL vs МСД

← →
Dimaxx © (2003-12-15 01:52) [0]

Почему операции с памятью на KOL выполняются в несколько раз медленнее? Есть модуль шифрования AES. Так вот на тестовом файле в 200 кб VCL затратил 32 мс, а KOL ажно 110 мс!!! Мал размером, но как черепаха.

Я писал себе прогу для поиска в файлах нужных данных, так VCK мегабайт пробегает как лань, в то время как KOL ползет в час по чайной ложке. VCL на 15 МБ файл затратил около 10 секунд, а KOL - больше минуты! В чем замес?

← →
SPeller © (2003-12-15 03:39) [1]

Код в студию!

← →
Yury Sidorov (2003-12-15 13:46) [2]

Если при компиляции KOL программы используется замена системных библиотек, то работа с памятью будет медленней чем без замены.

← →
SPeller © (2003-12-15 15:20) [3]

> Если при компиляции KOL программы используется замена системных
> библиотек, то работа с памятью будет медленней чем без замены.

Это почему?

← →
ecm (2003-12-15 15:49) [4]

А не используется ли случайно HeapMM? - он значительно меньше по объему но медленнее...
Надо посмотреть не вызывается ли где SetMemoryManager

← →
ecm (2003-12-15 15:59) [5]

З.Ы. Особенно заметно под Win98

← →
Yury Sidorov (2003-12-15 18:16) [6]

2 Speller: Потому, что в измененных системных библиотеках менеджер памяти заменяется на более простой и медленный (через Windows Heap).

Вот выдержка из readme по замене:

*** Overblotted Delphi memory manager is replaced by very simple one,
which just calls LocalAlloc, LocalFree, LocalReAlloc. (It is yet possible
to call UseDelphiMemoryManager to restore it, or to call SetMemoryManager
to setup your own memory manager).

← →
SPeller © (2003-12-15 19:19) [7]

Понятно. А если использовать стандартный, то на сколько увеличится код?

← →
Vladimir Kladov (2003-12-15 21:21) [8]

неужели так сложно попробовать? чем задавать вопрос, чтобы кто-нибудь попробовал, и через сутки или двое ответил. Если вообще найдется такой неленивый, что за другого ленивого пробовать станет :)

← →
SPeller © (2003-12-15 21:49) [9]

Предварительно мне придётся рытся и искать где же всё-таки этот нестандартный влючается, потому что я вообще понятия не имею где это и как. И в обозримом будущем заниматься этим не планирую. Так зачем мне тратить несколько часов на ответ где же это подключается/отключается и на тестирование, если можно спросить? Тот кто всё это придумал хотябы примерно должен знать отличия. Я ведь не прошу "вешать точно в граммах" :-))

← →
SPeller © (2003-12-15 21:50) [10]

вешать точно в байтах :)

← →
Vladimir Kladov (2003-12-16 15:09) [11]

It is yet possible to call UseDelphiMemoryManager
И сколько же часов надо, чтобы это прочитать? И применить, а?

← →
Dimaxx © (2003-12-17 01:26) [12]

А вот ровно столько, сколько прошло с момента написания темы и до времени написания сего ответа. Спасибо! У меня тока dcu, а в них не написано.

> It is yet possible to call UseDelphiMemoryManager
> И сколько же часов надо, чтобы это прочитать? И применить,
> а?

Сначала надо найти где именно это написано. System.pas он всё-таки не 2 килобайта весит. Вот сразу бы и сказали где читать. А вот теперь второй вопрос: где этот вызов прописывать?

← →
Yury Sidorov (2003-12-17 12:57) [14]

Это написано в readme.txt, выдержку из которого я приводил выше. Даже в приведенной выдержке это есть. :)

В разделе инициализации чтоли system.pas ?

← →
Yury Sidorov (2003-12-17 14:40) [16]

Вызывать UseDelphiMemoryManager нужно чем раньше, тем лучше. Т.е. лучше всего это делать в инициализации модуля, который первым прописан в uses в DPR файле. Можно сделать модуль-пустышку, которые только и будет делать, что устанавливать менеджер памяти.
P.S. Можно конечно и system.pas править, но мороки с перекомпиляцией много.

Теперь понятно.

> Можно конечно и system.pas править, но мороки с перекомпиляцией
> много.

Я у себя настроил makefile и теперь перекомпиляция у меня в "один клик":

make and move dcus to kol-sys.cmd:
del Sys_KOL_dcu\*.* make.exe > output.txt move /Y Sys_KOL_dcu\*.* C:\Programs\KOL\sys

Так что, не проблема :)

Работа с памятью: KOL vs МСД Найти похожие ветки