LINUX.ORG.RU

Аллокатор для пачки объектов

 ,


0

1

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

// allocate all 
int alloc_group(size_t item_size,size_t nr_of_items,void **save_pointers_here);
// freeing not-null`s
int free_group(size_t nr_of_items,void **take_pointers_from_here);

ps/ предвосхищая замечания - пулы объектов, это хорошо, но их тоже надо быстро пополнять и время от времени чистить; - просто хапнуть большой кусок item[nr_of_items] тоже нельзя, каждый объект живёт своей жизнью и освобождается раньше/позже прочих

★★★★★

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

Sorcerer ★★★★★
()
Последнее исправление: Sorcerer (всего исправлений: 1)

Ну так двусвязный список же? Заранее хапается место, и из него делается список свободных блоков. По мере надобности блоки из этого списка переносятся в список занятых, а потом назад.

AIv ★★★★★
()
Ответ на: комментарий от AIv

как в перволиспах.

и двухсвязность путём разностей в одном поле.

qulinxao ★★☆
()

А зачем? Если такая библиотека и существует, то внутри она всё равно пачку вызовов за тебя будет делать.

tcmalloc лучше используй.

mv ★★★★★
()

Твои требования в первом после либо противоречат друг другу, либо неточно обозначены. Объекты выделяются/освобождаются одними и теми же пачками? Если нет («каждый объект живёт своей жизнью и освобождается раньше/позже прочих»), то тебе нужен обычный pool аллокатор, от пачек профита не будет, за исключением, разве что, возможности сократить число malloc'ов (т.к. сразу знаем сколько выделять). В таком случае твои alloc/free_group - просто convenience обёртки над аллокатором.

slovazap ★★★★★
()
Ответ на: комментарий от mv

tcmalloc

оно падучее.

ну и под потоки заточено, о чём тс не упоминал.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.