Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Sm0ke, Вы писали:

S>>Тут надо замерять по скорости нужен ли такой аллокатор? По сути операционная система сама должна выдавать эти адреса оптимально, будет ли выигрыш?
S>>Потом при освобождении надо в аллокаторе помечать элемент, как освободившийся, чтобы потом снова его выдавать при выделении, но не может его вернуть операционной системе отдельно без всего pre-alloc блока. Стоит ли заморачиваться с такой хитровыфигованной системой, когда проще сделать в лоб?

MD>Естественно, что бенчмарки наше всё в такой ситуации, но
MD>1) Ходить к ОС ножками — явно недёшево, можно напороться на syscall. Косвенно на это намекают всякие фреймворки, которые сперва просят большой шмат памяти у системы, а затем обживаю его по надобности.

Так вот куда в приложении память утекла

Это оказывается фреймворки рвут куски от системы

Я конечно шучу тут, но и да, и нет.

MD>2) Само собой, ОС не знает, что там у нас с собственными внутренними аллокациями. С её точки зрения нам выдали целый кусок мяса, и вернуть лишь часть от него — никак (разве что попытаться сделать realloc на меньший размер, но тут гарантий опять же нет). Поэтому возвращать всё сразу, по ведомости ОС.

realloc — не работает
Надо определять rare case когда можно вернуть полностью невыданный bucket, если он не last. Хотя после list.clear() это может быть и не так уж rare.
Сложность в чём. Вот вернули мы bucket, а он сразу опять понадобился. Значит придётся для Пула писать Trait автовозвращения Бакетов. Автоматом или по требованию.

Здравствуйте, Mr.Delphist, Вы писали:

MD>Здравствуйте, Sm0ke, Вы писали:

S>>Тут надо замерять по скорости нужен ли такой аллокатор? По сути операционная система сама должна выдавать эти адреса оптимально, будет ли выигрыш?
S>>Потом при освобождении надо в аллокаторе помечать элемент, как освободившийся, чтобы потом снова его выдавать при выделении, но не может его вернуть операционной системе отдельно без всего pre-alloc блока. Стоит ли заморачиваться с такой хитровыфигованной системой, когда проще сделать в лоб?

MD>Естественно, что бенчмарки наше всё в такой ситуации, но
MD>1) Ходить к ОС ножками — явно недёшево, можно напороться на syscall. Косвенно на это намекают всякие фреймворки, которые сперва просят большой шмат памяти у системы, а затем обживаю его по надобности.

Так вот куда в приложении память утекла

Это оказывается фреймворки рвут куски от системы

Я конечно шучу тут, но и да, и нет.

MD>2) Само собой, ОС не знает, что там у нас с собственными внутренними аллокациями. С её точки зрения нам выдали целый кусок мяса, и вернуть лишь часть от него — никак (разве что попытаться сделать realloc на меньший размер, но тут гарантий опять же нет). Поэтому возвращать всё сразу, по ведомости ОС.

realloc — не работает
Надо определять rare case когда можно вернуть bucket (содержащий только не выданные итемы), и если он не last. Хотя после list.clear() это может быть и не так уж rare.
Сложность в чём. Вот вернули мы bucket, а он сразу опять понадобился. Значит придётся для Пула писать Trait автовозвращения Бакетов. Автоматом или по требованию.