Работа с памятью
Я как-то затронул тему арен, хочу про них рассказать в контексте управления памятью. Давайте пробежимся по ручному управлению памятью, Reference Counting и сборщику мусора (GC). Ручное управление — все топорно и просто. Мы сами следим за освобождением памяти. Reference Counting - Runtime подсчитывает количество ссылок на объекты. Они хранятся в памяти, пока их больше 0, а как только становится 0 — очищаются оттуда. Сборщик мусора (gc) - память освобождается самостоятельно. Кто-то может подумать, что он работает по подсчёту ссылок, но это не так. Вариант, когда 2 объекта ссылаются друг на друга в предыдущем примере не позволит высвободить память, т.к счётчик будет равен 1. Сборщик мусора затрагивает ресурсы cpu и его работа вызывает stop the world. С развитием сборщиков мусора в языках, эти проблемы стпли не столь критичны, как раньше. Работу сборщика мусора можно улучшить путём использования арен, области памяти, которая освобождена от управления gc. Боевой пример — grpc. В результате парсинга proto в памяти создаётся большое количество мелких объектов, что не очень хорошо сказывается на производительности. Арены повышают производительность не только при работе с gc. Сам процесс выделения/освобождения памяти, если мы говорим про ручное управление, так же вызывает накладные расходы. Если вдруг вам показалось, что arena - супер друпер штука и её надо везде использовать. То нет. Arena занимает больше памяти, чем если бы работали по старинке.
