Comments 9
Реквестирую табличку с замерами производительности «до» и «после». Иначе не понятно, стоила ли игра свеч (вдруг проблема была в другом?)
maaGames Думаю, что в рамках данной статьи вам придется поверить мне на слово. Тема всё-таки была в освещении базовых идей на отстраненном примере. Реализация аллокатора — простейшая.
Но, я согласен, что было бы неплохо иметь представление о применении аллокатора на примере более приближенном к действительности. И с замерами. Обязуюсь исправиться в очередной статье.
Но, я согласен, что было бы неплохо иметь представление о применении аллокатора на примере более приближенном к действительности. И с замерами. Обязуюсь исправиться в очередной статье.
Как вариант, использовать кастомный аллокатор с std::unique_ptr.
С помощью шаблонных using pool_ptr и make_pool этот вариант тоже можно прихорошить, по удобству будет во многом не хуже shared_ptr.
Когда будете делать замеры производительности, рассмотрите и этот вариант тоже ;)
Переходя в раздел «ненормальное программирование», можно предложить вообще обходиться без указателей. Иерархию наследования преобразовывать в boost::variant. На практике, конечно, я бы не советовал везде пихать такие «извращения».
С помощью шаблонных using pool_ptr и make_pool этот вариант тоже можно прихорошить, по удобству будет во многом не хуже shared_ptr.
Когда будете делать замеры производительности, рассмотрите и этот вариант тоже ;)
Переходя в раздел «ненормальное программирование», можно предложить вообще обходиться без указателей. Иерархию наследования преобразовывать в boost::variant. На практике, конечно, я бы не советовал везде пихать такие «извращения».
Универсальный вариант — это правильно написанный allocator rebind и продуманная организация пулов по типам и размерам объектов и контекстам их использования. Дело в том, что rebind используется также при работе с различными контейнерами, поэтому передача нужного аллокатора куда надо также может существенно повлять на производительность. При этом непродуманная политика аллоцирования приводит к потреблению большого количества памяти.
Без указателей-то можно обходиться, но если объекты большие и их прийдется часто копировать, то это опять же плохо скажется на производительности.
Без указателей-то можно обходиться, но если объекты большие и их прийдется часто копировать, то это опять же плохо скажется на производительности.
Вроде бы в C++17 хотят добавить возможность определить размеры управляющей структуры для STL структур — если сделают, то будет портабельный способ использовать пул для shared_ptr/list/map и т.д.
Для данного описанного случая (особенно если weak_ptr для этого типа объектов не нужен) может оказаться лучшим выходом переделка shared_ptr на intrusive_ptr.
Для данного описанного случая (особенно если weak_ptr для этого типа объектов не нужен) может оказаться лучшим выходом переделка shared_ptr на intrusive_ptr.
А можете описать, чем intrusive_ptr лучше, чем shared_ptr/make_shared?
При использовании intrusive_ptr реализация самого механизма подсчета ссылок ложится на класс объекта. Со всеми вытекающими расходами на хранение дополнительных данных(счетчиков). Сам intrusive_ptr просто уведомляет о необходимости уменьшить или увеличить счетчик. Ну и понимает когда нужно удаляться.
В этом случае нет надобности хранить что-то верх самого объекта. А размер объекта может быть легко вычислен через sizeof.
В этом случае нет надобности хранить что-то верх самого объекта. А размер объекта может быть легко вычислен через sizeof.
Sign up to leave a comment.
std::shared_ptr и кастомный аллокатор