Comments on: Visual Studio 2008 new test features http://khason.net/blog/visual-studio-2008-new-test-features/ Take care of the sense, and the sounds will take care of themselves. Sun, 14 Mar 2010 16:12:15 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Noticias externas http://khason.net/blog/visual-studio-2008-new-test-features/comment-page-1/#comment-939 Noticias externas Thu, 01 Jan 2009 08:29:20 +0000 http://khason.net/blog/visual-studio-2008-new-test-features/#comment-939 <p>Referring my disappointment from the topics on 70-552 , I start looking on new test features, provider</p> Referring my disappointment from the topics on 70-552 , I start looking on new test features, provider

]]> By: Greg Young http://khason.net/blog/visual-studio-2008-new-test-features/comment-page-1/#comment-938 Greg Young Thu, 01 Jan 2009 08:29:19 +0000 http://khason.net/blog/visual-studio-2008-new-test-features/#comment-938 <p>I think the big problem with the current profiling is that you substantially change what you are looking at by measuring (HUP).</p> <p>When the profiler instruments the IL before JIT many JIT optimizations get 'un-done'. A great example of this is inlining ... As such it is common that one receives many false positives of pain points (note I am referring more here to fairly micro optimizations but in a substantially complex set of code (say something doing hard core transactional processing in memory) it becomes nearly useless for all but the biggest problems (which are generally also pretty easy to find philosophically)</p> <p>As such I have found that I end up injecting my own measurements at various boundaries ... Even though this will still slow the execution of the system it does not change the output of the JIT compiler ...</p> I think the big problem with the current profiling is that you substantially change what you are looking at by measuring (HUP).

When the profiler instruments the IL before JIT many JIT optimizations get 'un-done'. A great example of this is inlining … As such it is common that one receives many false positives of pain points (note I am referring more here to fairly micro optimizations but in a substantially complex set of code (say something doing hard core transactional processing in memory) it becomes nearly useless for all but the biggest problems (which are generally also pretty easy to find philosophically)

As such I have found that I end up injecting my own measurements at various boundaries … Even though this will still slow the execution of the system it does not change the output of the JIT compiler …

]]>