Почему сборка мусора на сервере происходит быстрее, если я не собираю мусор?

Question

Я пишу структуру данных, и если я установлю <gcServer enabled="true" /> в моем app.config файл, программа добавляет 500 000 элементов в 200 миллисекунд. Если я установлю <gcServer enabled="false" /> это займет 300 миллисекунд. То есть, если установить этот флаг в значение false, он будет занимать на 50% больше времени, что измеряется Stopwatch,

Мне интересно, почему это происходит, потому что я не занимаюсь сборкой мусора. Я знаю, что иногда это делается автоматически, но после профилирования с помощью CLRProfiler я могу подтвердить, что происходит 0 сборов:

Кто-нибудь знает, почему это происходит? Если сборщик мусора даже не работает, то почему сборщик мусора на сервере намного быстрее? Вот код, где я проверяю разницу в скорости:

Stopwatch sw = Stopwatch.StartNew();

foreach (string s in items)
{
    dataStructure.Add(s, s + "a");
}

sw.Stop();

Answer 1

Вот пять вещей, которые мне нужно охватить.

Во-первых, понимание того, что этот флаг не включает или выключает сборщик мусора, а просто определяет, какой режим он использует. В обоих примерах включена сборка мусора; только первый (более медленный) пример использовал сборку мусора на сервере.

Второе - это понимание того, что сборы не выполнялись, это не значит, что сборщик мусора никогда не останавливался, чтобы проверить, нужно ли запускать сборник.

В-третьих, это выдержка из gcServer документы:

Для однопроцессорных компьютеров сборка мусора на рабочей станции по умолчанию должна быть самой быстрой опцией.

В-четвертых, понимание "единого процессора" в вышеприведенном контексте действительно относится к процессорам, а не к ядрам.

Соберите все это вместе, и поведение вопроса точно соответствует документации. Двигаться вперед; здесь ничего нет.

В-пятых, и наконец, понимание значений в игре и того, как загрузка сервера отличается от нагрузки на рабочий стол. Основное значение в серверной системе - стабильность. Это верно даже по сравнению с производительностью; производительность не имеет значения, если система постоянно падает. Кроме того, серверы с большей вероятностью будут выполнять рабочие нагрузки, когда процесс имеет длительный срок службы... даже месяцы или годы без перезапуска. Таким образом, администратор сервера может пожертвовать некоторой производительностью, чтобы получить GC, который выполняется немного чаще и выполняет более полную проверку, которая может включать сжатие памяти для восстановления адресного пространства и, таким образом, избежать проблем с исключениями OutOfMemoryExceptions, которые в противном случае могут вызвать проблемы в долговременном.Net приложения.