Фаза метки сборки мусора .Net и огромные связанные списки

Question

Если существует связанный список с узлами 4M +, должна ли фаза марки проходить весь список каждый раз, чтобы построить график? Есть ли какие-либо оптимизации, применяемые в этом случае? На вид это не выглядит эффективным. Есть ли способ проверить, пересекает ли GC весь список или нет?

ТИА.

Answer 1

Что сказал Джон.

Кроме того, как только объект попадает в Gen2, доступна оптимизация (в Windows, но не на других платформах IIRC), что GC может зарегистрироваться в ядре для уведомлений для данногостраница памяти.В тех случаях, когда страница остается неизменной между событиями GC, некоторые операции не нужно повторять.

Answer 2

Существует одна очень важная оптимизация..NET GC является поколением, и данные в gen2 просматриваются очень редко.

При больших структурах данных (таких как огромные связанные списки) большинство ваших данных быстро попадут в gen2, где GC будетредко обращайтесь к нему.

Кроме того, сборщик мусора только просматривает живые данные во время сбора, мертвые данные собираются "бесплатно".Поэтому, когда ваш список становится недоступным (или если большинство его узлов, но не все, это делают), GC сможет собирать миллионы узлов в основном бесплатно.

Answer 3

Да, ему нужно будет пройти весь граф объекта. Честно говоря, я не могу думать, как могут быть какие-либо оптимизации, но это не требует особых усилий для каждого узла. Я подозреваю, что большую часть времени, вероятно, будет потрачено на ожидание в памяти, поскольку очевидно, что он будет прожигать кеш. Конечно, к тому времени, когда связанный список заканчивается в gen2 (и если вы выделяете миллионы узлов, большая часть будет в gen2 довольно быстро), он будет делать это очень редко.

Если это наиболее приемлемая структура данных для вашего приложения, я бы использовал ее на данный момент, но отслеживаю снижение производительности при сборке мусора с помощью Performance Monitor и т. Д. Если это окажется проблемой, вы можете рассмотреть альтернативные стратегии.