Зачем проектировать собственный менеджер памяти?

Question

Я разработал простой Менеджер хранилища фиксированных блоков (SM) и Диспетчер памяти общего назначения в прошлом.В обоих случаях я выделяю большой кусок памяти кучи при запуске и снова и снова использую освобожденную память, предотвращая частые вызовы на дорогие вызовы malloc / new .

Если я говорю о Фиксированный блок SM ( Github link) , то я практически видел выигрыш в производительности, который он приносит.В моем случае это было примерно на 40% улучшение при распределении случайных размеров.

Но в случае универсального менеджера памяти ( Github link ) (без пулов памяти) я не видел видимого прироста производительности.Единственный выигрыш, который я увидел, - это доступ к статистике использования памяти.С точки зрения производительности она снижается из-за накладных расходов, связанных с определением свободных блоков (во время выделения) и расположения памяти на карте (во время освобождения).

Поэтому мой вопрос заключается в том, в каком сценарии был бы пользовательский распределитель памяти общего назначения.полезно?Стоит ли усилий?

Answer 1

Производительность - не единственная причина разработки собственного распределителя.Другие причины могут включать:

1. Лучше Возможности отладки .
   Не было бы неплохо иметь диспетчер памяти, который может помочь в обнаружении некоторых распространенных ошибок программирования, таких как использование неинициализированной памяти, доступ к памяти вне выделенного блока, двойное освобождение, использование после освобождения?Однако хороший диспетчер памяти ОС может уже предлагать все эти возможности "из коробки".
2. Внедрение памяти Квоты использования .
   В более крупных проектах вы можете беспокоиться о памятисвиньи, особенно если используются сторонние модули.Лучше не допустить, чтобы у мошеннического модуля все остальные модули голодали.
3. Гарантированное распределение .
   Иногда вы хотите убедиться, что определенная критическая функция никогда не выйдет из строя.Предварительное выделение большого куска памяти и предоставление пользовательского распределителя может быть одним из необходимых шагов.
4. Принудительная очистка памяти после ненадежных плагинов.
   Защита приложения от таких же нездоровых сценариевкак и в случае с памятью.
5. A автономная система может вообще не иметь никакого менеджера памяти.: -)

Answer 2

Редко возникает необходимость в разработке собственного менеджера памяти. Их так много, что большинство людей могут найти тот, который можно использовать со стойки. Несколько лет назад у меня была система C ++, которая включала переводчик. В начальном тестировании это было не так быстро, как мы надеялись. Профилирование показало, что проблема заключалась в распределении памяти, и это обнаружилось в строковом классе. Мы загрузили около двух десятков менеджеров памяти из Интернета и попробовали каждый из них по очереди. Мы смогли добиться значительного улучшения скорости. Диспетчер памяти, который мы в итоге использовали, всегда выделял блоки с размерами, кратными 2, и поддерживал отдельные пулы для каждого размера блока.

Мы нашли больше менеджеров памяти, чем могли бы протестировать.