Предположим, есть некое нагромождение разных контейнеров, реализующих NoSQL-БД в памяти. Все эти контейнеры используют std::allocator.

Занимает это всё в рабочем режиме, допустим, 100 гигов.


Есть другая часть программы, отвечающая за пост-обработку данных в ходе каждого запроса, приём соединений, отвечаниями на запросы. Например, выдернуть из основного хранилища 128 каких-нибудь элементов, хитро отсортировать, найти для первых 20 ещё что-нибудь и засунуть в сокет в виде своего бинарного протокола...

Эта "другая часть" тоже оперирует разными контейнерами, стандартными и нестандартными, но все они юзают std::allocator, хотя конечно сами и создаются на стеке.

Как сильно я облегчу потребление памяти процессом в результате дефрагментации, если "сниму нагрузку" с std::allocator из "другой части"? Скажем, создам аллокатор типа POOL, который всегда держит выделенными 100 мегабайт, отдаёт потребителям кусочки с начала, а после обработки запроса сдвигает указатель на начало?

На самом деле пул-аллокатор свой сделан и я делаю эксперименты, смотрю на графики потребления памяти. Идея была в том, чтобы снять нагрузку с std::allocator, чтобы все "new" случившиеся в ходе обработки одного запроса заменились на тупой сдвиг указателя, а по окончании запроса двигать указатель на начало пула. Графики говорят, что особенного выигрыша нет. С std::allocator график более рваный, но в конечном итоге он дрыгается вокруг стабильного значения и утечек от фрагментации особо страшных я не вижу. С моим аллокатором график более ровный, но других особых преймуществ, кроме ровности графика, я не вижу, может быть скорость работы программы, но это не мерялось.

Конечно new - это не вызов в ядро и даже не библиотечный malloc каждый раз, а всего-лишь ключевое слово языка, на которое компилятор рожает вызов конструктора, но как он выделит под объект память в куче - не факт, что это всегда будет дороже, чем мой сдвиг указателя.

Короче говоря, дело тёмное, нужен НИОКР.

smaldsherzod_1. Выделяются много _равных по размеру_ участков памяти (хотя этот случай современными аллокаторами тоже отрабатывает хорошо, системного вызова скорее не произойдет, как и блокировки).


Вызовы происходят, просто сделайте свой аллокатор,
пропишите в allocate, construct, deallocate, destroy выводы отчётов с std::cout
передайте аллокатор в контейнеры, делайте insert, erase, reserve, push и пр.
и смотрите на вывод в консоль. Узнаете много интересного про политики
управления памятью, реализованные в контейнерах.

ЗЫ std::allocator не делет в плане оптимизации управления памятью ничего,
он просто делает new, delete. Политика управления памятью есть в контейнерах,
она своя для каждого, и, судя по выводам std::cout, очень не оптимальна, заточена
под общий случай.
Я так игрался когда-то. Эта политика примерно понятна, ясно в целом как себя ведут разные контейнеры, не в этом дело. Дело в том, что даже обычный new может быть не так дорог как мне кажется. Это может на практике обернуться тоже каким-нибудь тупым сдвигом указателя... Ну например, во freebsd, насколько я слышал, есть (помимо тупой кучи) пулы с кусочками по 8, 16, 32, 64, 128... байт памяти, одна из защит от фрагментации. Сколько там таких чудес я точно не знаю )

Проблема в том, что для хранения данных используется контейнер btree - это дерево такое, которое иногда при вставке новых данных проводит операции убиения старых нодов, чтобы заместить их нодами увеличенного размера ( 64 -> 128 -> 256 -> 512 ). Нужен аллокатор, который помнит размеры выделенных кусков, иначе потери от хранения ненужных данных в POOL-аллокаторе превысят размер памяти, используемой для хранения служебной информации в std::allocator.

С чем-то типа std::map, который при вставке не занимается никакими удалениями этот фокус прокатывает лучше.

Меня тут посетила мысль. Когда наступают такие условия в b-tree, при которых ему захотелось увеличить некий узел в 2 раза, то он выделяет 2*N байт памяти, а освобождает N байт (я смотрел код гуглового, который у меня используется). Получается, что у кучи попросили 2*N байт, а освободили N. То есть, при постоянной вставке объектов, btree-контейнер периодически бросает мелкие куски, а просит куски больше старых - то есть делает такие запросы в кучу, которые не могут быть удовлетворены за счёт выдачи клиенту освобождённых им в прошлом блоков. Никому больше эта дырка в куче размером в N байт не нужна.

Хотя btree ведь выделяет когда-то и блоки по N байт, если это совсем новый узел. Или стандартный алгоритм выделения памяти не сканирует кучу на предмет поиска мелких дырок подходящего размера? Разве у него нет списка дырок в каком-нибудь быстром индексе, чтобы быстро их находить?