Николай Зверев возражает/добавляет насчёт "FM и использование памяти"

"Это к посту про FM:

http://18delphi.blogspot.ru/2013/10/fm.html

Я тоже может сейчас не в тему напишу. Но всё зависит от решаемых задач.

В наших проектах есть такая вот вещь - свои датасеты. В обычном режиме там память под каждую запись (row) выделяется в общей куче. Но есть режим пула - когда в один момент времени выделяется память... скажем для 10000 записей. А дальше записи берутся из пула (и возвращаются обратно).

И это даёт прирост в скорости. Но только в старых версиях Delphi со старым менеджером памяти. С FastMM прирост не вооружённым глазом не заметен даже на очень большом кол-ве записей (моё любимое кол-во записей для тестов - 6 миллионов).

Или вот ещё пример - VirtualTreeView. Там тоже есть режим пула для выделяемых нод. Картинка та же самая.

И даже если сложить выигранное время там плюс тут - то с секундомером пользователь может и заметит разницу, но с таким объёмом данных никто локально не работает.

Ну и ещё я как-то делал оптимизации динамических массивов - типа выделяем сразу большое кол-во элементов (типа Capacity) и отдельно храним кол-во актуальных элементов. По скорости - оно конечно быстрее, чем постоянно делать SetLength(array, Length(array) + 1), но на такой маленький процент... в общем я решил, что пусть код будет проще, чище и понятнее.

Другое дело, элементы графики, с которыми активно взаимодействует пользователь, тут оптимизация конечно нужна.

А если вспомнить Ваш текстовый процессор, то там наверняка одно слово - это отдельный объект. Слов в документе тысячи, документов тоже не мало, понятно, что тут игра тоже стоит свеч.

Ну и про FM моё мнение такое. Задумка отличная, архитектура продуманная, оптимизация хромает. Но на всё нужны ресурсы. Пусть пилят, мы подождём."

-- по делу всё написано. Мне так кажется.