Boost.Pool: различия между версиями

Во-первых, куча не бесконечна. Даже на больших системах (т. е. не встраиваемых) с огромным количеством виртуальной памяти существует предел. Все знают о физическом пределе памяти, но существует более тонкий, «виртуальный» предел, предел, после которого ваша программа (или система в целом) замедляется из-за использования виртуальной памяти. Ваша программа намного ближе к данному виртуальному пределу, чем к физическому, особенно на многозадачных системах. Поэтому, когда вы запускаете программу на большой системе, неплохо, если ваша программа использует самый минимум ресурсов и освобождает их как можно быстрее. Если же вы запускаете программу на встраиваемой системе, обычно у вас вообще нет памяти разбрасываться и нужно тщательно контролировать ее расход.<br />

Во-вторых, куча имеет сложное внутреннее устройство. Она выполняет запросы на выделение различных типов памяти, разного размера и должна делать это быстро. Обычный подход к управлению памятью заключается в разбиении памяти на порции и хранении информации о данных порциях в виде упорядоченного по размеру дерева или списка. Добавьте сюда такие параметры как расположение в глобальной/локальной памяти (locality), расчетное время жизни (estimating life time) и куча станет очень сложной. Настолько сложной, что просто не существует исчерпывающего ответа как лучше всего динамически выделять память. Диаграмма ниже иллюстрирует работу большинства менеджеров памяти: для каждого блока памяти (chunck) они используют часть памяти для хранения внутреннего дерева или списка. Даже когда блок памяти выделен программе, менеджер памяти вынужден хранить часть информации о нем — обычно это размер. Тогда при освобождении блока памяти менеджер легко может определить его размер.<br />

 

'''''Динамическое выделение памяти часто неэффективно'''''