Здравствуйте, ·, Вы писали:

S>> Или всю память заполнили, а потом начинаем бороться с GC?
·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.

Ne кстати не заметил

Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения.
И соответственно огромные тормоза при изменении огромного количества ссылок.
http://rsdn.org/forum/dotnet/415352.1

Автор: Serginio1
Дата: 20.10.03

Это нужно учитывать. Посмотри на дату. Сейчас может все по другому.
Кстати по алгоритму то и получается, что кэш

 var bytes = new byte[80 * 1024]; 
    random.NextBytes(bytes);
    bytesCache.Set(bytes.GetHashCode(), bytes);

bytesCache будет постоянно обновляться. Поэтому если bytesCache будет постоянно в 0 поколении, то и задержки будут постоянными

Суть в том, что bytesCache никаким кэшем не является.
Можно кстати для интереса не менять ссылки, а копировать содержимое. Благо размер походит.
Просто в реалиях
1. Кэш изменяется редко.
2. Не генерируется и не записывается такое количество в кэш.

Вот кстати статья про
«барьер записи» (write barrier), который сводится к обновлению card table, если адрес записываемого объекта находится в эфемерном сегменте (ephemeral segment), т.е. является молодым объектом 0-го или 1-го поколений.

https://habrahabr.ru/post/155847/