[C, C++] Многократное выделение/освобождение памяти

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

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

Во, кстати, про эту фрагментацию памяти -- чего расскажешь? А то пол-интернетов орут, что фрагментация памяти -- сказка, остальные уверяют, что она -- страшное и ужасное явление, и для защиты от... нужно купить суперпрограмму, которая память дехрюкментировать будет. Истина, как всегда, посередине?

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

А как определить, что проблемы начались именно из-за фрагментации памяти? Есть какие методики?

ну это обычно когда у тебя ОС говорит что твоя программа жрет много памяти, а в твоей программе какой-нибудь heapwalk говорит что куча памяти свободна ... тоесть при выделении памяти не используется свободная память, т.к. в ней все блоки памяти очень маленькие, а выделяется новая ...

А чтобы не дожидаться истерики операционки? Есть какие-нить профилировщики, что ли, для определения степени фрагментируемости памяти приложением?

если все запросы на аллокацию будут одинакового размера, то дефрагментации не будет. Все объекты должны быть равны!

Не, у меня не будет никакой демократии, равенства и политкорректности.

> Чем чревато многократное выделение/освобождение памяти (new / delete)?

Тем, что это дорогая операция.

> Тем, что это дорогая операция.

Как лечить? Самописный менеджер памяти -- не лучшее решение.

аллокатор должен держать (и реализации реально держат) наготове списки преаллокированных кусков памяти небольших размеров.

Поэтому если все идет по плану, то new/delete сводится просто к перебрасыванию указателя из списка свободных блоков в список занятых и обратно.

ну там ещё проблема в том что при выделении/освобождении памяти обычно критическая сессия захватывается ... а это дорогая операция ...

*секция конечноже, опечатался как обычно ...

можно тонкую обёртку написать к malloc чтобы выделял блоки кратного размера(имхо). Это если совсем приспичит :)

> критическая сессия захватывается

Виндузятник detected.

> можно тонкую обёртку написать к malloc чтобы выделял блоки кратного размера(имхо).

Pooling allocation называется. И желательно выделять память целыми страницами, а их уже резать на отдельные куски под объекты. При высвобождении этих кусков сваливать их в списочек, из которого можно их потом быстро достать. Ну и сборщик мусора в каком-нибудь цикле или по таймеру, чтобы отдавать пустые страницы системе.

Ах да, и не надо new/malloc(). mmap()!

>>Тем, что это дорогая операция.

в общем случае неверно, т.к.

* For large (>= 512 bytes) requests, it is a pure best-fit allocator,
with ties normally decided via FIFO (i.e. least recently used).
* For small (<= 64 bytes by default) requests, it is a caching
allocator, that maintains pools of quickly recycled chunks.
* In between, and for combinations of large and small requests, it does
the best it can trying to meet both goals at once.
* For very large requests (>= 128KB by default), it relies on system
memory mapping facilities, if supported.

про фрагментацию тут много обсуждали, в частности по примеру старого FF и jemalloc. Ищи. Die-Hard и кто-то ещё эту тему ковыряли.

>>А то пол-интернетов орут, что фрагментация памяти -- сказка,

Они видимо не использовали FF под Linux.

>>А то пол-интернетов орут, что фрагментация памяти -- сказка,
> Они видимо не использовали FF под Linux

FF - это уже прошлое. Яркий пример существующей в настоящее время проблемы - X.org, который у меня умудряется хавать 200 Mb на пустом рабочем столе (если не перезапускать иксы несколько дней):
   SZ     RSS  STIME    TIME    CMD
32687   19184  Nov09  00:00:28  kded4
33178   36916  Nov09  00:00:38  pidgin
35916   38076  Nov09  01:59:25  /usr/bin/konsole
36843   42016  Nov09  00:00:27  /usr/bin/krunner
39803   72796  Nov09  02:56:02  kwin
43686  184740  Nov09  04:00:47  /usr/bin/X -br -nolisten tcp :0 vt7 -auth /var/run/xauth/A:0-0aJISd
44142   74864  Nov09  00:15:41  amarokapp
58022  167288  Nov09  01:44:52  /usr/bin/plasma

> ну там ещё проблема в том что при выделении/освобождении памяти обычно критическая сессия захватывается ... а это дорогая операция

С каких пор "критическая секция" - дорогая операция? Как в форточках, так и в лине в норме ничего за пределы юзерспейса обычно не выходит.

> С каких пор "критическая секция" - дорогая операция?

Сериализуются потоки на ней.

> С каких пор "критическая секция" - дорогая операция? Как в форточках, так и в лине в норме ничего за пределы юзерспейса обычно не выходит.

я думал оно там пожизни в ядро уходит ...

> Сериализуются потоки на ней

Пардон, не осилил. Это как? Или "сериализация" - это то, что я привык называть синхронизацией?

> я думал оно там пожизни в ядро уходит

В ядро уходит только в случае возникновения коллизии для ожидания другого потока.

> Пардон, не осилил. Это как? Или "сериализация" - это то, что я привык называть синхронизацией?

В очередь сукины дети выстраиваются -- сериализуются.

> В очередь сукины дети выстраиваются -- сериализуются

"Всю жизнь" считал, что сериализация чего-либо - это преобразования в последовательность байтов, а "выстраивание в очередь" - это синхронизация. И не вижу причин менять свои взгляды.

> А как определить, что проблемы начались именно из-за фрагментации памяти? Есть какие методики?

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

Еще можно ввести счетчик выделенного и освобожденного и вычислить разницу между тем сколько было отъедено у ОС и сколько занято полезными данными. Это потери на фрагментацию. Когда оные станут большими - начать беспокоиться. Да, если у тебя разработка идет на одной платформе, то счетчик кодить не надо - скорее всего в отладочной версии libc/msvcrt/что-у-тебя-там он будет. Он просто не стандартизирован.