Информация об изменениях

Сообщение Re[39]: dotnet vs java 2016-2020 от 14.10.2016 6:31

Изменено 14.10.2016 7:59 Serginio1

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

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


S>>·>А из-за чего?

S>>·>Кстати, это тоже камень в огород c#. Диагностика таких вот тонких проблем очень проблематична. Сложно (если вообще возможно) докопаться до причины тормозов.
S>> Это свойство Windows. Есть еще куча сервисов и приложений.
·>Угу, с этим тоже борются, ещё один камень в огород c# — он win-only, а в винде тоже всё плохо с LL. Я приводил ссылочку на ютуб с подробным рассказом — как борются в линухе. Вот исходники https://github.com/epickrram/perf-workshop Покажи как бы ты боролся с этим же в виндах и каких бы показателей смог достичь.
Есть кроссплатформенный .Net Core и .Net Native
·>В общем, если у тебя есть другие тесты, дающие другие результаты — давай показывай. А пока ты просто пустословно споришь против статьи, и даже не с её автором.

Ну во первых ты привел тест без сравнения с Java.
Во вторых

 // Use 80K, If we are > 85,000 bytes = LOH and we don't want these there
    var bytes = new byte[80 * 1024]; 
    random.NextBytes(bytes);
    bytesCache.Set(bytes.GetHashCode(), bytes);


Then to ensure that the objects are kept around long enough, they are both put into a Least Recently Used (LRU) cache, that holds the 2000 most recent items.


Размер кэша 2000*80*1024 = 163 мб.
Я уж не знаю какая там скорость памяти, но явно это больше 4 мс.
При этом кэш постоянном обновляется ибо очень мала вероятность получить одинаковые массивы.
При таком подходе проще сериализовать данные и записывать в Redis или другие NoSQL базы.
Re[39]: dotnet vs java 2016-2020
Здравствуйте, ·, Вы писали:

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


S>>·>А из-за чего?

S>>·>Кстати, это тоже камень в огород c#. Диагностика таких вот тонких проблем очень проблематична. Сложно (если вообще возможно) докопаться до причины тормозов.
S>> Это свойство Windows. Есть еще куча сервисов и приложений.
·>Угу, с этим тоже борются, ещё один камень в огород c# — он win-only, а в винде тоже всё плохо с LL. Я приводил ссылочку на ютуб с подробным рассказом — как борются в линухе. Вот исходники https://github.com/epickrram/perf-workshop Покажи как бы ты боролся с этим же в виндах и каких бы показателей смог достичь.
Есть кроссплатформенный .Net Core и .Net Native
·>В общем, если у тебя есть другие тесты, дающие другие результаты — давай показывай. А пока ты просто пустословно споришь против статьи, и даже не с её автором.

Ну во первых ты привел тест без сравнения с Java.
Во вторых

 // Use 80K, If we are > 85,000 bytes = LOH and we don't want these there
    var bytes = new byte[80 * 1024]; 
    random.NextBytes(bytes);
    bytesCache.Set(bytes.GetHashCode(), bytes);


Then to ensure that the objects are kept around long enough, they are both put into a Least Recently Used (LRU) cache, that holds the 2000 most recent items.


Размер кэша 2000*80*1024 = 163 мб.
Я уж не знаю какая там скорость памяти, но для дефрагментации памяти явно это больше 4 мс потребуется.
При этом кэш постоянном обновляется ибо очень мала вероятность получить одинаковые массивы.
При таком подходе проще сериализовать данные и записывать в Redis или другие NoSQL базы.