Сообщение Re[31]: dotnet vs java 2016-2020 от 13.10.2016 11:43
Изменено 13.10.2016 12:04 Serginio1
Здравствуйте, ·, Вы писали:
S>> Или всю память заполнили, а потом начинаем бороться с GC?
·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.
Ne кстати не заметил
Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения.
И соответственно огромные тормоза при изменении огромного количества ссылок.
http://rsdn.org/forum/dotnet/415352.1
Это нужно учитывать. Посмотри на дату. Сейчас может все по другому.
Кстати по алгоритму то и получается, что кэш
bytesCache будет постоянно обновляться. Поэтому если bytesCache будет постоянно в 0 поколении, то и задержки будут постоянными
Суть в том, что bytesCache никаким кэшем не является.
Можно кстати для интереса не менять ссылки, а копировать содержимое. Благо размер походит.
Просто в реалиях
1. Кэш изменяется редко.
2. Не генерируется и не записывается такое количество в кэш.
S>> Или всю память заполнили, а потом начинаем бороться с GC?
·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.
Ne кстати не заметил
Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения.
И соответственно огромные тормоза при изменении огромного количества ссылок.
http://rsdn.org/forum/dotnet/415352.1
Автор: Serginio1
Дата: 20.10.03
Дата: 20.10.03
Это нужно учитывать. Посмотри на дату. Сейчас может все по другому.
Кстати по алгоритму то и получается, что кэш
var bytes = new byte[80 * 1024];
random.NextBytes(bytes);
bytesCache.Set(bytes.GetHashCode(), bytes);
bytesCache будет постоянно обновляться. Поэтому если bytesCache будет постоянно в 0 поколении, то и задержки будут постоянными
Суть в том, что bytesCache никаким кэшем не является.
Можно кстати для интереса не менять ссылки, а копировать содержимое. Благо размер походит.
Просто в реалиях
1. Кэш изменяется редко.
2. Не генерируется и не записывается такое количество в кэш.
Re[31]: dotnet vs java 2016-2020
Здравствуйте, ·, Вы писали:
S>> Или всю память заполнили, а потом начинаем бороться с GC?
·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.
Ne кстати не заметил
Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения.
И соответственно огромные тормоза при изменении огромного количества ссылок.
http://rsdn.org/forum/dotnet/415352.1
Это нужно учитывать. Посмотри на дату. Сейчас может все по другому.
Кстати по алгоритму то и получается, что кэш
bytesCache будет постоянно обновляться. Поэтому если bytesCache будет постоянно в 0 поколении, то и задержки будут постоянными
Суть в том, что bytesCache никаким кэшем не является.
Можно кстати для интереса не менять ссылки, а копировать содержимое. Благо размер походит.
Просто в реалиях
1. Кэш изменяется редко.
2. Не генерируется и не записывается такое количество в кэш.
Вот кстати статья про
«барьер записи» (write barrier), который сводится к обновлению card table, если адрес записываемого объекта находится в эфемерном сегменте (ephemeral segment), т.е. является молодым объектом 0-го или 1-го поколений.
https://habrahabr.ru/post/155847/
S>> Или всю память заполнили, а потом начинаем бороться с GC?
·>Память когда нибудь заполняется. В том тесте через 5 минут, на реальном сервере через 5 часов или 5 дней, не важно. Делать всё равно что-то придётся.
Ne кстати не заметил
Но в свое время была проблема, когда изменялись данные, которые находились в старших поколениях, для них GC делал движения, для того, что бы учесть эти изменения.
И соответственно огромные тормоза при изменении огромного количества ссылок.
http://rsdn.org/forum/dotnet/415352.1
Автор: Serginio1
Дата: 20.10.03
Дата: 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/