Здравствуйте. Уже поднимал подобную тему раньше, но тогда решения не нашел, а сейчас оно снова стало актуально.
Избавляюсь от прямого использования boost в заголовках своей библиотеки. Некоторые классы оной включают очень большие количества мелких объектов, выделяемых на куче. Например, есть объект, который содержит std::list других таких же объектов, и такая иерархия образует гигантское дерево. Все эти объекты имеют одинаковый тип (не наследуются), а, значит, одинаковый размер, и мне бы логично хотелось бы складывать их в какой-то pool, а не фрагментировать кучу легионом мелких объектов. Поэтому, я обратился к сабжу. Тогда я еще везде дергал boost, поэтому включение подобных заголовков во все заголовки движка меня ни капли не смущало. Но с приходом новых версий С++ необходимость тянуть boost везде пропала, и теперь только этот аллокатор, затягивая с собой еще кучу бутовских хидеров (например, mpl!), обеспечивает мне процентов 25 всего размера препроцесснутых исходников, а, значит, и времени компиляции. Поэтому, я хочу от него избавиться. Какие варианты решения:
1. Просто про него забыть и использовать стандартный. Вроде бы на PC этот аллокатор особенного выигрыша в скорости не давал, но на мобилках разница была очень даже заметна. Замедлять работу программы ради скорости компиляции как-то не хочется.
2. Поискать в интернете замену. Там полно разных велосипедов, и у всех свои неоспоримые преимущества и свои неустранимые баги. И у всех разная совместимость с разными компиляторами и архитектурами. Не хотелось бы влипнуть в какую-то несовместимость в самый неподходящий момент.
3. Написать самому. Я не уверен, что у меня достаточно компетенции, чтобы сходу написать что-то, что будет работать настолько быстро и устойчиво, чтобы заменить стандартный аллокатор из STL.
Что посоветуете? Меня бы устроил простейший (даже однопоточный, так даже лучше) хидер-онли аллокатор, написаный без сложных платформенных вывертов, заточенный под хранение и частое удаление / создание мелких объектов равного размера, исключающий при этом постоянное непосредственно обращение к операциям кучи. Грубо говоря, "выделяю чанк на 1024 объекта указанного размера, и, если места не хватит, выделяю новый". Все.
Здравствуйте, Went, Вы писали:
W>Что посоветуете? Меня бы устроил простейший (даже однопоточный, так даже лучше) хидер-онли аллокатор, написаный без сложных платформенных вывертов, заточенный под хранение и частое удаление / создание мелких объектов равного размера, исключающий при этом постоянное непосредственно обращение к операциям кучи. Грубо говоря, "выделяю чанк на 1024 объекта указанного размера, и, если места не хватит, выделяю новый". Все.
Здравствуйте, MNZ, Вы писали:
MNZ>Здравствуйте, Went, Вы писали:
W>>Что посоветуете? Меня бы устроил простейший (даже однопоточный, так даже лучше) хидер-онли аллокатор, написаный без сложных платформенных вывертов, заточенный под хранение и частое удаление / создание мелких объектов равного размера, исключающий при этом постоянное непосредственно обращение к операциям кучи. Грубо говоря, "выделяю чанк на 1024 объекта указанного размера, и, если места не хватит, выделяю новый". Все.
MNZ>Если на проекте используется C++17, то можно попробовать взять стандартные std::pmr::unsynchronized_pool_resource и std::pmr::polymorphic_allocator: https://en.cppreference.com/w/cpp/header/memory_resource.
Увы, пока что ограничен С++11. И, по-моему, указанный аллокатор (точнее, ресурс памяти) заточен под блоки разной длины, то есть будет априори неоптимален для моей задачи. Или я неверно прочитал?
Здравствуйте, Went, Вы писали:
W>Здравствуйте, MNZ, Вы писали:
MNZ>>Здравствуйте, Went, Вы писали:
W>>>Что посоветуете? Меня бы устроил простейший (даже однопоточный, так даже лучше) хидер-онли аллокатор, написаный без сложных платформенных вывертов, заточенный под хранение и частое удаление / создание мелких объектов равного размера, исключающий при этом постоянное непосредственно обращение к операциям кучи. Грубо говоря, "выделяю чанк на 1024 объекта указанного размера, и, если места не хватит, выделяю новый". Все.
MNZ>>Если на проекте используется C++17, то можно попробовать взять стандартные std::pmr::unsynchronized_pool_resource и std::pmr::polymorphic_allocator: https://en.cppreference.com/w/cpp/header/memory_resource. W>Увы, пока что ограничен С++11. И, по-моему, указанный аллокатор (точнее, ресурс памяти) заточен под блоки разной длины, то есть будет априори неоптимален для моей задачи. Или я неверно прочитал?
Да вроде всё верно. Только про оптимальность лучше не судить умозрительно, а сделать конкретные замеры. Я сам этим аллокатором не пользовался — только бустовским, — и по сравнению с new он быстрее раз в пять.
