Memory Allocation (plain C)

obstack тебе в руки

да и обычный стек не пренебрегай

>да и обычный стек не пренебрегай

старался - не везде есть возможность, поэтому собственно и спросил.

В glib есть memory chunk как они это называют

Memory chunks provide an efficient way to allocate *_equal-sized_* pieces of memory, called atoms.

тоесть не катит

как минимум мне не удалось найти никого кто их пользует

http://developer.gimp.org/api/2.0/glib/glib-Memory-Chunks.html

Memory Chunks — deprecated way to allocate groups of equal-sized chunks of memory.

+ "... and current versions do not have it at all"

Выделение памяти это "больная" тема. В том смысле, что если исходно программа написана так, что постоянно дергает malloc()/realloc()/free(), то ни какой аллокатор не спасет, тут алгоритм менять надо.

>То есть все идет к тому что не проще ли заюзать свой memory allocator - то есть выделить сразу большой кусок и разбить его на области в соотвествии с размерами, создать там кеш запросов на выделение - ну и так далее так далее.

Не знаю, стоит ли называть аллокатором массив буферов и другие алгоритмические решения, позволяющий не очень часто вызывать malloc()/free().

>Вопрос в том - стоит ли делать это самому (для меня это развлекалово и не так то и долго я буду имплементить) ?

Если демон является "развлекаловом" и пишется, там не знаю, для зачета или курсовой, то особого смысла что либо улучшать я не вижу. А если вы начинаете долгий проект, который потом будут кодить другие люди...

>Да и хотелось бы узнать про ньюансы других *nix систем (не linux+glibc) в этой связи.

Не совсем понятен вопрос. malloc() был везде, а когда начнете писать свой аллокатор, работающи через mmap(), там и узнаете "ньюансы" :)

>>Да и хотелось бы узнать про ньюансы других *nix систем (не linux+glibc) в этой связи.

>Не совсем понятен вопрос. malloc() был везде, а когда начнете писать свой аллокатор, работающи через mmap()

человеку как раз mmap и мешает жить... Ибо медленный

dlmalloc великолепно конфигурируется под куски памяти любого размера. делается это банальной правкой значений макросов в хидере. http://g.oswego.edu/dl/html/malloc.html

> (выделять приходится куски от 32 до 512 байт)

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

Тут недавно ссылку давали: http://goog-perftools.sourceforge.net/doc/tcmalloc.html

это не то, что вы ищите?

али ето: http://g.oswego.edu/dl/html/malloc.html

> али ето: http://g.oswego.edu/dl/html/malloc.html

там ссылка не работает на исходный код... поэтому вот: http://gee.cs.oswego.edu/pub/misc/malloc.c http://gee.cs.oswego.edu/pub/misc/malloc.h

по ссылке написано что эта штука тестировалось только под линукс/глибс

а человека кросплатформенность ещё интересует...

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

> куски от 32 до 512 байт

тогда не легче ли что то типа slab-allocator'а смастерить?

Разработчики GLib предлагают использовать вот такой распределитель памяти: http://library.gnome.org/devel/glib/unstable/glib-Memory-Slices.html

>тогда не легче ли что то типа slab-allocator'а смастерить?

вот я думаю ...

>Разработчики GLib предлагают использовать вот такой распределитель памяти: http://library.gnome.org/devel/glib/unstable/glib-Memory-Slices.html

он во многом не подходит - и не хочу я юзать glib

> смутило что она не возвращает память системе. Я думаю это не есть хорошо особенно для монстрообразных приложений

Главное что бы не выпадали за пределы адресного пространства (а оно не должно, раз переиспользоваться будет), а сколько неиспользованных страниц будет вымещено в своп и будет споконо там себе лежать без использования в каждый данный момент времени - это на скорость стрельбы не влияет.

Да, насчет кроссплатформености.. Куча - это же просто алгоритм, к железу не особо привязанный, и посему должен работать везде.. Хотя что там кроме *никсов для запуска демонов используют?

как тебе сказать - она привязана к некросплатформенным системным вызовам.

отсюдова алгоритмы должны менятся вместе со сменой железки и платформы

Можно использовать идею пула соединений к базе данных. То есть, имеем некоторую прослойку-аллокатор (кеш), через который выделяем/удаляем память. Основная идея состоит в том, что при удалении памяти, ее необязательно удалять сразу же из пула - можно попридержать в надежде, что кто-то запросит ее снова.

Вообще, у такого подхода есть параметры, и их следует корректировать. Если часто выделяются куски одного размера, то будет определенный выигрыш. Тут еще нужно учитывать вариабельность размеров этих кусков (от 32 до 512) - поэтому есть над чем еще подумать.