LINUX.ORG.RU

История изменений

Исправление KivApple, (текущая версия) :

Во-первых, далеко не каждый проект. Выделение памяти далеко не всегда узкое место. А преждевременная оптимизация плохо.

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

В-третьих, бывает, что ты работаешь со специфическим классом объектов. Например, много объектов одного размера (эффективно держать их пул, а не выделять по одному в куче). Или тебе может быть нужна сборка мусора (например, ты пишешь свой скриптовой ЯП). Тогда обычные аллокации ты делаешь обычным аллокатором, а особые аллокации своим аллокатором.

Короче, сильно зависит от задачи. И в общем случае свой аллокатор не пишут, только в частном.

Исправление KivApple, :

Во-первых, далеко не каждый проект. Выделение памяти далеко не всегда узкое место. А преждевременная оптимизация плохо.

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

В-третьих, бывает, что ты работаешь со специфическим классом объектов. Например, много объектов одного размера (эффективно держать их пул, а не выделять по одному в куче). Или тебе может быть нужна сборка мусора (например, ты пишешь свой скриптовой ЯП). Тогда обычные аллокации ты делаешь обычным аллокатором, а особые аллокации своим аллокатором.

Короче, сильно зависит от задачи. И в общем случае свой аллокатор не пишут, только в частном.

Исходная версия KivApple, :

Во-первых, далеко не каждый проект. Выделение памяти далеко не всегда узкое место. А преждевременная оптимизация плохо.

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

В-третьих, бывает, что ты работаешь со специфическим классом объектов. Например, много объектов одного размера (эффективно держать их пул, а не выделять по одному в куче). Или тебе может быть нужна сборка мусора (например, ты пишешь свой скриптовой ЯП). Тогда обычные аллокации ты делаешь обычным аллокатором, а особые аллокации своим аллокатором.

Короче, сильно зависит от задачи. И в общем случае свой аллокатор не пишут, только в частном.