Я слышал, что для того, чтобы язык правильно реализовал и запускал сборку мусора, требуется в среднем 3 раза больше требуемой памяти. Я не уверен, что это предполагает, что приложение небольшое, большое или либо.
Итак, я хотел знать, есть ли какое-либо исследование или действительно количество сборок на сборку мусора. Также я хочу сказать, что GC - очень приятная функция.
Объем необходимой памяти зависит от скорости распределения внутри вашей программы. Если у вас высокий уровень распределения, вам нужно больше места для роста, пока работает GC.
Другим фактором является время жизни объекта. Если ваши объекты, как правило, имеют очень короткий срок службы, тогда вы сможете управлять с чуть меньшим запасом с коллекционером поколений.
Есть много исследовательских работ, которые могут вас заинтересовать. Я немного позже отредактирую для ссылки на некоторые.
Изменить (январь 2011):
Я думал о конкретной статье, которую я, похоже, сейчас не могу найти. Ниже приведены интересные и содержащие некоторые данные о производительности. Как правило, вы, как правило, в порядке с объемом в два раза больше памяти, доступной в качестве вашей резидентной программы. Некоторым программам требуется больше, но другие программы будут работать очень хорошо даже в ограниченных средах. На это влияет множество переменных, но наиболее важна скорость распределения.
Мифы и реальность: влияние сборки мусора
Изменить (февраль 2013 г.): это редактирование добавляет сбалансированную перспективу на цитированную статью, а также рассматривает возражения, поднятые Тимом Купером.
Количественная оценка эффективности сборки мусора против явного управления памятью, как отметил Натан Еллин, на самом деле является ссылкой, которую я сначала пытался вспомнить в Январь 2011 года. Однако я не думаю, что интерпретация, предложенная Натаном, верна. Это исследование не сравнивает GC с обычным ручным управлением памятью. Скорее, он сравнивает GC с оракулом, который делает идеальные явные релизы. Другими словами, это не дает нам знать, насколько хорошо обычное ручное управление памятью сравнивается с магическим оракулом. Это также очень сложно найти, потому что исходные программы либо написаны с учетом GC, либо с учетом ручного управления памятью. Таким образом, любой бенчмарк сохраняется во внутреннем уклоне.
После возражений Тима Купера, я хотел бы уточнить свою позицию по теме памяти. Я делаю это в основном для потомков, так как считаю, что ответы на переполнение стека должны служить долгосрочным ресурсом для многих людей.
В типичной системе GC имеется много областей памяти, но три абстрактных вида:
Что такое высота? Высота зала - это минимальное количество зарезервированного пространства, необходимого для поддержания желаемого уровня производительности. Я считаю, что об этом спрашивал ОП. Вы также можете подумать о запасе в качестве дополнительной памяти для реальной резиденции программы (максимальная живая память), необходимой для хорошей производительности.
Да - увеличение запаса может задержать сбор мусора и увеличить пропускную способность. Это важно для автономных некритических операций.
В действительности большинство проблемных областей требуют решения в реальном времени. Есть два вида реального времени, и они очень разные:
Большинство современных сборщиков мусора нацелены на soft-realtime, что хорошо для настольных приложений, а также для серверов, которые предоставляют услуги по требованию. Если один из них исключает реальное время в качестве требования, можно также использовать стоп-мир сборщика мусора, в котором запасы начинают терять смысл. (Примечание: приложения с преимущественно короткоживущими объектами и высокая скорость распределения могут быть исключением, поскольку коэффициент выживаемости низкий.)
Теперь предположим, что мы пишем приложение с требованиями к мягкому режиму реального времени. Для простоты предположим, что GC работает одновременно на выделенном процессоре. Предположим, что программа имеет следующие искусственные свойства:
и
Теперь мы можем увидеть следующую временную шкалу событий со скоростью распределения A:
Временная шкала событий со скоростью распределения B отличается:
Обратите внимание, как скорость распределения напрямую влияет на размер требуемого запаса? При скорости распределения B нам требуется вдвое больший запас, чтобы предотвратить паузы и поддерживать тот же уровень производительности.
Это был очень упрощенный пример, призванный проиллюстрировать только одну идею. Есть много других факторов, но он показывает, что было предназначено. Имейте в виду другой важный фактор, о котором я упомянул: средний срок жизни объекта. Короткие времена жизни вызывают низкую выживаемость, которые работают вместе со скоростью распределения, чтобы влиять на объем памяти, необходимый для поддержания заданного уровня производительности.
Короче говоря, нельзя предъявлять общие требования к требуемому запасу, не зная и не понимая характеристики приложения.
В соответствии с исследованием 2005 года "Количественное определение эффективности сбора мусора против явного управления памятью" (PDF) коллекторы сборщиков мусора нуждаются в 5 раз больше памяти для достижения равной производительности. Удел ниже мой:
Мы сравниваем явное управление памятью как с копировальными, так и с копировальными сборщиками мусора по целому ряду эталонных тестов и включаем реальные (не имитируемые) прогоны, которые подтверждают наши результаты. Эти результаты количественно определяют компромисс между сборкой мусора во времени: с объемом памяти в пять раз, коллективный сборщик мусора в стиле Appel с не копирующим зрелым пространством соответствует производительности явного управления памятью. Только с в три раза больше памяти, он работает в среднем на 17% медленнее, чем явное управление памятью. Однако, только в два раза больше памяти, сбор мусора снижает производительность почти на 70%. Когда физической памяти мало, пейджинг заставляет сбор мусора работать на порядок медленнее, чем явное управление памятью.
Я надеюсь, что оригинальный автор четко обозначил то, что они считают правильным использованием сбора мусора и контекстом их требований.
Накладные расходы, безусловно, зависят от многих факторов; например, накладные расходы являются более значительными, если вы часто запускаете сборщик мусора; копировальный сборщик мусора имеет более высокие накладные расходы, чем сборщик меток и развертки; и гораздо проще написать сборщик мусора с более низкими накладными расходами в однопоточном приложении, чем в многопоточном мире, особенно для всего, что перемещает объекты (копирование и/или уплотнение gc).
Итак, я хотел знать, есть ли какое-либо исследование или действительно количество сборок на сборку мусора.
Почти 10 лет назад я изучил две эквивалентные программы, которые я написал на С++, используя STL (GCC на Linux) и в OCaml, используя свой сборщик мусора. Я обнаружил, что С++ в среднем использует в два раза больше памяти. Я попытался улучшить его, написав специализированные STL-распределители, но никогда не смог сопоставить память OCaml.
Кроме того, GC обычно выполняют много уплотнений, что еще больше уменьшает площадь памяти. Поэтому я бы бросил вызов предположению о том, что накладные расходы на память по сравнению с обычным неуправляемым кодом (например, С++, используя то, что теперь является стандартными библиотечными коллекциями).