Здравствуйте, chaotic-good, Вы писали:
CG>По поводу влияния остального кода на сложность и стоимость сборки мусора — это IMO главный недостаток языков с GC. Тут мы тестим фунцию и все ок, а там мы используем ее в приложении, которое имеет совсем другой характер нагрузки на сборщик мусора и получается совсем другой результат. Получается что кусок кода нельзя рассматривать отдельно performance wise и это не что иное как отсутствие модульности.
Бред мягко говоря. Неэффективный код будет плохо работать независимо от места использования.
Просто в языках с GC надо считать не только циклы процессора, но и аллокации.
При ручном управлении памятью аллокации напрямую отражаются в CPU usage, а с GC получаются отложенные затраты.
Из той же презентации:
You can speculate and hypothesize all you want…
If you’re not measuring, you’re just guessing.
For managed code, the profiler of choice is PerfView
LMBTFY: http://www.bing.com/search?q=PerfView+download
http://www.microsoft.com/en-us/download/details.aspx?id=28567
