Сообщение Re[7]: Garbage collection vs manual memory management от 14.01.2015 10:43
Изменено 14.01.2015 10:47 chaotic-good
G>
Я бы не сказал что это противоречит тому, о чем я говорил, впрочем ладно, думаю из нашей дискуссии и так уже можно сделать достаточно полезных выводов
G>>>Bpexfnm jnc.lf — http://codeblog.jonskeet.uk/2014/08/01/object-pooling-and-thread-safety/ и далее по ссылкам.
CG>>Плохая статья, метод измерения производительности неизвестен. Он как-то бенчмаркает и потом делает выводы, но как — неизвестно. Может у него тест слишком короткий и в gen 2 этот string builder не успевает попасть.
G>Ты наверное не в курсе, что jonskeet это крутейший чувак по C#. Автор множеств книг и №1 на SO http://stackoverflow.com/users?tab=Reputation&filter=all
G>Я его мнению доверяю больше, чем всем "экспертам" на этом форуме. И тебе советую.
Я знаю кто это такой, читал его книгу и статьи. Суть в том, что тем не менее, дядя не публикует свои бенчмарки для этой статьи, следовательно, все что он в ней пишет — не имеет никакого значения. У него там долгоживущий string builder, который, насколько я понмю, содержит внутри себя ссылку на буфер, которая может меняться при использовании builder-а. Можно написать benchmark так, что эта ссылка не будет меняться никогда (буфер не будет ресайзиться, так как форматируется все время строка одной и той же длины), collection cost в тесте может быть очень низким, так как кроме самого теста никто не создает нагрузку на GC, поэтому полная сборка не будет отражаться на производительности. В реальном же коде все может быть совсем не как в бенчмарке. В реальном коде можно дернуть эту функцию, сформатировать что-нибудь объемное, что вызовет аллокацию и изменение ссылок в долгоживущем string builder-е, что в свою очередь вызовет полную сборку мусора, которая будет дорогой, а не дешевой как в benchmark-е. Может моя интуиция относительно этого и не верна и Скит правильно все делает, но я этому не поверю все равно пока сам не пощупаю или не увижу код теста. Вот такая вот у меня политика относительно бенчмарков
G>
Truth #3
G>Allocations are king
G>Time spent in the garbage collector harms responsiveness
G>Average delays ≈ (Collection rate) × (Collection cost)
G>Average delays ≈ (Allocation rate) × (Heap size)
G>Corollary: Allocate less
G>Less often (reduce collection rate)
G>Smaller, fewer long-lived objects (reduce heap size)
Я бы не сказал что это противоречит тому, о чем я говорил, впрочем ладно, думаю из нашей дискуссии и так уже можно сделать достаточно полезных выводов
G>>>Bpexfnm jnc.lf — http://codeblog.jonskeet.uk/2014/08/01/object-pooling-and-thread-safety/ и далее по ссылкам.
CG>>Плохая статья, метод измерения производительности неизвестен. Он как-то бенчмаркает и потом делает выводы, но как — неизвестно. Может у него тест слишком короткий и в gen 2 этот string builder не успевает попасть.
G>Ты наверное не в курсе, что jonskeet это крутейший чувак по C#. Автор множеств книг и №1 на SO http://stackoverflow.com/users?tab=Reputation&filter=all
G>Я его мнению доверяю больше, чем всем "экспертам" на этом форуме. И тебе советую.
Я знаю кто это такой, читал его книгу и статьи. Суть в том, что тем не менее, дядя не публикует свои бенчмарки для этой статьи, следовательно, все что он в ней пишет — не имеет никакого значения. У него там долгоживущий string builder, который, насколько я понмю, содержит внутри себя ссылку на буфер, которая может меняться при использовании builder-а. Можно написать benchmark так, что эта ссылка не будет меняться никогда (буфер не будет ресайзиться, так как форматируется все время строка одной и той же длины), collection cost в тесте может быть очень низким, так как кроме самого теста никто не создает нагрузку на GC, поэтому полная сборка не будет отражаться на производительности. В реальном же коде все может быть совсем не как в бенчмарке. В реальном коде можно дернуть эту функцию, сформатировать что-нибудь объемное, что вызовет аллокацию и изменение ссылок в долгоживущем string builder-е, что в свою очередь вызовет полную сборку мусора, которая будет дорогой, а не дешевой как в benchmark-е. Может моя интуиция относительно этого и не верна и Скит правильно все делает, но я этому не поверю все равно пока сам не пощупаю или не увижу код теста. Вот такая вот у меня политика относительно бенчмарков
Re[7]: Garbage collection vs manual memory management
G>
Я бы не сказал что это противоречит тому, о чем я говорил, впрочем ладно, думаю из нашей дискуссии и так уже можно сделать достаточно полезных выводов
G>>>Bpexfnm jnc.lf — http://codeblog.jonskeet.uk/2014/08/01/object-pooling-and-thread-safety/ и далее по ссылкам.
CG>>Плохая статья, метод измерения производительности неизвестен. Он как-то бенчмаркает и потом делает выводы, но как — неизвестно. Может у него тест слишком короткий и в gen 2 этот string builder не успевает попасть.
G>Ты наверное не в курсе, что jonskeet это крутейший чувак по C#. Автор множеств книг и №1 на SO http://stackoverflow.com/users?tab=Reputation&filter=all
G>Я его мнению доверяю больше, чем всем "экспертам" на этом форуме. И тебе советую.
Я знаю кто это такой, читал его книгу и статьи. Суть в том, что тем не менее, дядя не публикует свои бенчмарки для этой статьи, следовательно, все что он в ней пишет — не имеет никакого значения. У него там долгоживущий string builder, который, насколько я понмю, содержит внутри себя ссылку на буфер, которая может меняться при использовании builder-а. Можно написать benchmark так, что эта ссылка не будет меняться никогда (буфер не будет ресайзиться, так как форматируется все время строка одной и той же длины), collection cost в тесте может быть очень низким, так как кроме самого теста никто не создает нагрузку на GC, поэтому полная сборка не будет отражаться на производительности. В реальном же коде все может быть совсем не как в бенчмарке. В реальном коде можно дернуть эту функцию, сформатировать что-нибудь объемное, что вызовет аллокацию и изменение ссылок в долгоживущем string builder-е, что в свою очередь вызовет полную сборку мусора, которая будет дорогой, а не дешевой как в benchmark-е. Может моя интуиция относительно этого и не верна и Скит правильно все делает, но я этому не поверю все равно пока сам не пощупаю или не увижу код теста. Вот такая вот у меня политика относительно бенчмарков
По поводу влияния остального кода на сложность и стоимость сборки мусора — это IMO главный недостаток языков с GC. Тут мы тестим фунцию и все ок, а там мы используем ее в приложении, которое имеет совсем другой характер нагрузки на сборщик мусора и получается совсем другой результат. Получается что кусок кода нельзя рассматривать отдельно performance wise и это не что иное как отсутствие модульности.
G>
Truth #3
G>Allocations are king
G>Time spent in the garbage collector harms responsiveness
G>Average delays ≈ (Collection rate) × (Collection cost)
G>Average delays ≈ (Allocation rate) × (Heap size)
G>Corollary: Allocate less
G>Less often (reduce collection rate)
G>Smaller, fewer long-lived objects (reduce heap size)
Я бы не сказал что это противоречит тому, о чем я говорил, впрочем ладно, думаю из нашей дискуссии и так уже можно сделать достаточно полезных выводов
G>>>Bpexfnm jnc.lf — http://codeblog.jonskeet.uk/2014/08/01/object-pooling-and-thread-safety/ и далее по ссылкам.
CG>>Плохая статья, метод измерения производительности неизвестен. Он как-то бенчмаркает и потом делает выводы, но как — неизвестно. Может у него тест слишком короткий и в gen 2 этот string builder не успевает попасть.
G>Ты наверное не в курсе, что jonskeet это крутейший чувак по C#. Автор множеств книг и №1 на SO http://stackoverflow.com/users?tab=Reputation&filter=all
G>Я его мнению доверяю больше, чем всем "экспертам" на этом форуме. И тебе советую.
Я знаю кто это такой, читал его книгу и статьи. Суть в том, что тем не менее, дядя не публикует свои бенчмарки для этой статьи, следовательно, все что он в ней пишет — не имеет никакого значения. У него там долгоживущий string builder, который, насколько я понмю, содержит внутри себя ссылку на буфер, которая может меняться при использовании builder-а. Можно написать benchmark так, что эта ссылка не будет меняться никогда (буфер не будет ресайзиться, так как форматируется все время строка одной и той же длины), collection cost в тесте может быть очень низким, так как кроме самого теста никто не создает нагрузку на GC, поэтому полная сборка не будет отражаться на производительности. В реальном же коде все может быть совсем не как в бенчмарке. В реальном коде можно дернуть эту функцию, сформатировать что-нибудь объемное, что вызовет аллокацию и изменение ссылок в долгоживущем string builder-е, что в свою очередь вызовет полную сборку мусора, которая будет дорогой, а не дешевой как в benchmark-е. Может моя интуиция относительно этого и не верна и Скит правильно все делает, но я этому не поверю все равно пока сам не пощупаю или не увижу код теста. Вот такая вот у меня политика относительно бенчмарков
По поводу влияния остального кода на сложность и стоимость сборки мусора — это IMO главный недостаток языков с GC. Тут мы тестим фунцию и все ок, а там мы используем ее в приложении, которое имеет совсем другой характер нагрузки на сборщик мусора и получается совсем другой результат. Получается что кусок кода нельзя рассматривать отдельно performance wise и это не что иное как отсутствие модульности.