> Счетчик ссылок на пару порядков быстрее CG.Неа. Во-первых, даже полностью статическое управление памятью не на порядки быстрее сборщика мусора. Наверное можно создать искусственную ситуацию, когда разница будет достигать порядка, но достичь этой ситуации в реальном проекте со сборщиком будет не так просто. Особенно если избегать её. При этом довольно сложно сравнивать сборщик мусора со статическим управлением памятью, потому что тут всё сильно-сильно зависит от того, чем именно программа занимается и как она это делает. Но тем не менее, ждать что сборка мусора замедлит программу хотя бы на порядок -- это ждать слишком многого. Я удивлюсь, если она замедлит хотя бы в два раза.
Во-вторых, счётчик ссылок -- это существенно не бесплатная абстракция: элементарная передача указателя из одного места в другое требует разадресации указателя и кеш-промахов для того чтобы изменить значение счётчика ссылок. Это может дать такие пенальти к производительности, что счётчик ссылок покажется раем.
Лет двадцать назад счётчики ссылок выглядели очень неплохо. Но все эти двадцать лет память по скорости отставала от процессоров всё дальше и дальше. И скорость процессора и частота памяти растут экспоненциально, но там в основании экспоненты стоят разные значения. Поэтому разница в скорости тоже растёт экспоненциально по времени. Я -- увы -- ссылку найти не могу с красивыми графиками и пояснениями, но ты можешь попробовать поверить мне на слово.
Сегодня речь идёт о том, что все структуры данных, типа списков, деревьев, и прочие способы размазывания данных ровным слоем по куче -- это не вариант для производительной программы. Скажем, лет десять назад народ ещё радостно прыгал, при словах "красно-чёрное дерево", и втирал что это гораздо лучше хеш-таблички. Сегодня фонтаны восхищения иссякли -- нужен быстрый ассоциативный массив? значит хеш-табличка, всё остальное имеет разве что академическое значение в рамках курса "история структур данных XX века". Хотя может для программирования микроконтроллеров эти знания ещё могут пригодиться.
Динамический массив оказывается быстрее списка даже несмотря на стоимость операции insert, просто потому что он меньше греет кеш. То есть если размер массива увеличивать в бесконечность, то с определённой точки начиная список окажется быстрее, но если массив влезает в килобайт, то он будет быстрее списка на операции insert. Особенно если перелопатить алгоритмы и постараться избегать insert/remove произвольных позиций, например, заменяя это чем-нибудь типа swap_remove или позволяя массиву иметь "дыры" и иногда дефрагментируя его. Зато список будет невыносимо медленнее массива при итерации по элементам.
Сборщик мусора тоже занимается тем, что "трогает" всю память доступную по указателям, засирая таким образом кеши, но он это делает несколько иначе. Даже ещё интереснее, сборщик мусора может работать на разных алгоритмах и эти разные алгоритмы могут быть более или менее удачны для разных ситуаций. Даже более того, он может менять стратегию в рантайме, скажем, затачиваясь на меньшие latency в программе, когда есть свободное ядро для сборщика мусора, и на максимальный throughput, когда программа отжирает 100% процессорного времени, сглаживая таким образом пиковые нагрузки. Кроме того, работа сборщика мусора может уменьшать количество кеш-промахов в основном коде программы. Это уменьшение может происходить уже за счёт того, что память менее фрагментирована, но если сборщик мусора написан с мыслью о том, чтобы снижать количество кеш-промахов, то он не просто дефрагментирует память, он может из списка сделать массив, в том смысле, что для программы список будет именно списком, но в памяти элементы будут лежать последовательно, прямо как в массиве.
Короче, если зачем-то нужны счётчики ссылок и без них никак, то лучше подумать о языке с GC, нежели писать на C, C++, Rust и тому подобных языках.
