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

S>>>Вот под это прекрасно подходят нативные менеджеры памяти.
S>·>Но не подходит .net. Что и требовалось доказать. Считаю вопрос закрытым.
S> Вопрос пока открыт пока не покажешь этот же самый код на Java.
Оплатишь моё потраченное время — покажу.

S>>>Да там может быть жуткая фрагментация.
S>·>Угу... Или не будет, если переизобретёшь явовский gc.
S> Я то не буду. Но как MS могут добавить еще один GC для таких вырожденных случаев.
Тут ведь как... Могут добавить, а могут и не добавить!
Да, кстати, java не стоит на месте: can manage 100GB+ heaps with the majority of the gc pauses requiring < 100ms.

S>>>Но можно сделать компромиссный GC с менеджером памяти.
S>·>Или не париться и взять java.
S> Я не пишу на Java. Ты так и не показал этот же тест на Java.
Я привёл ссылки на результаты бенчмарков Zing GC. И на результаты бенчмарков .net GC. Конкретные тесты меня не интересуют. Если у тебя есть другие результаты, показывай, не стесняйся. Пока ты тупо отрицаешь факты приведённые мной, не дав ничего взамен.

S> Только свои предположения. Возьми и напиши. Делов то. А я может и перейду на Java.
Для 1С оно тебе не нужно. Но переходи — денег больше платят.

S> Заодно и .Net Core протестируем.
S> Я думаю, что не только мне будет интересно посмотреть на результаты
Ну так я тебе показал результаты уже сделанных замеров. Тебя они не устраивают. Делай замеры сам, тут тебе будет не с кем спорить.

S>http://mattwarren.org/2016/08/08/GC-Pauses-and-Safe-Points/
S>https://www.azul.com/products/zing/pgc/
?? Это к чему?
Ты решил доказать мне то, что я доказываю тебе?

some point in time the GC will need to clean up all the garbage and to do this is has to pause the entire runtime (except if you happen to be using Azul’s pauseless GC for Java)

S> Хотя лично считаю, что для этого лучше всего подойдет C++ с хорошим менеджером памяти.
Т.е. .net не подходит. Что и требовалось доказать. Считаю вопрос закрытым.