Ручки вместо указателей: как избавиться от «паутины объектов» в C++
Handles are the better pointers (2018)
Автор делится опытом 15+ лет работы с большими C++ кодовыми базами, где умные указатели порождают медленный код, фрагментацию памяти и «фейковые утечки». Решение — централизованные системы владеют массивами объектов, а наружу отдают индексные ручки вместо указателей. Это упрощает отладку, ускоряет работу за счёт кэша и добавляет проверки безопасности. Подход плохо ложится на классический ООП, но хорошо сочетается с data-oriented архитектурой.
Самый худший случай — десятки или сотни тысяч маленьких C++ объектов, каждый в своей куче, которые указывают друг на друга через умные указатели.
- boricj
Вот именно так я и сделал на работе в своём встраиваемом проекте.
Пулы объектов, с индексами и поколениями. Гораздо, гораздо проще, чем возиться с сырыми указателями, дешевле, чем shared_ptr/weak_ptr, и не требуется никакой очистки при удалении объектов, потому что сохранённое поколение не совпадёт с поколением нового объекта. Можно даже сделать это конструируемым по умолчанию, если также увеличивать поколение при создании экземпляра (так что живыми будут только чётные поколения), и скрыть всё это за высокоуровневыми абстракциями на C++.
Хотя мои знания этих техник пришли из архитектур видеоигр 2000-х, так как известно, что игры вроде GTA: Vice City их используют.
- nickwanninger
Моя диссертация посвящена этой теме, и несколько лет назад у меня была статья на ASPLOS о поддержке памяти на основе хендлов в неуправляемых языках (C/C++) через LLVM: https://nickw.io/papers/asplos24-alaska.pdf
Накладные расходы, которые мы там наблюдали, на удивление обусловлены только накладными расходами на инструкции и ветвления от использования программных хендлов — у меня есть текущая работа по реализации этого в аппаратуре, и накладные расходы там намного ниже.
- Conscat
Я всерьёз попытался программировать таким образом в своём проекте на C++ (во многом из-за этой статьи), и лично мне это показалось крайне обременительным, потому что приходится таскать владельца этого ресурса повсюду, где хочешь использовать хендл. Это само по себе может ухудшить производительность, когда он находится в разных функциях, это затруднило обобщённое программирование, и такой код должен быть более насыщен шаблонами, и его было трудно рефакторить.
Но это был очень низкоуровневый проект, и я подозреваю, что Floooh, вероятно, имел в виду скорее конечные приложения.