Comments 13
Можете привести пример, как используя эти знания можно оптимизировать код приложения и сделать его более производительным?
Кто нибудь может объяснить, почему именно этот алгоритм выбран, а не на основе кол-ва ссылок?
Подсчет ссылок не решает проблему циклических ссылок. Собственно, в том же python именно поэтому есть и reference counting и generational gc
Понял. Т.е. это единственная причина, по которой выбран алгоритм, страдающий от остановки мира? Просто хочу уточнить. А то для себя я за годы уже привык избегать структур с циклическими ссылками. Вот мне и кажется, что это меньшее зло, чем использовать алгоритм с таким проблемами производительности. Я оговорюсь, что очень большой проблемой я это не считаю, но судя по кол-ву статей на эту тему, как в русскоязычной, так и в англоязычной сфере, кто-то всё же считает это проблемой. Так вот, если это всё же проблема, то почему же выбран алгоритм, подверженный этой проблеме? Неужели всего-лишь из-за того, что он может обрабатывать циклические ссылки?
Сборщики мусора могут не только удалять не используемые объекты, но и, например, еще выполнять memory compaction или дефрагментацию. Насчет stw, то почти все современные gc прибегают к нему. В статьях, обычно, критикуют именно выбор достаточно старого и простого трехцветного алгоритма.
По поводу избегания циклических ссылок, то тут не все так однозначно. Пока кодовая база маленькая и количество разработчиков коммитящих в нее немного, то все ок. Но по мере роста команды и кода за этим будет следить все сложнее, да и в сторонних либах может быть все что угодно)
по поводу избегания циклических ссылок: но ведь если они нужны для реализации графа который по бизнес-логики заложен - как избавиться от такого? делать менее оптимальные варианты через матрицу смежности?
отличная статья, спасибо! ждём ещё
будет ли статья по тому, как работает планировщик горутин?
Go's Garbage Collection: как работает и почему это важно знать