Visual Studio 2008 new test features

19 בנובמבר 2007

תגובה אחת

[This blog was migrated. You will not be able to comment here.
The new URL of this post is]

Referring my disappointment from the topics on 70-552, I start looking on new test features, provider by Visual Studio 2008. I worked with performance analyzer in VS2005 (which is looked much more like debug tools for .NET CLR developers in MS) and today, after public release of VS2008, I can show you my research.

From the first sight, it looks like nothing changed



But when we're digging deeper, we discover new interesting features.


Look in this. My application decodes jpegs most of the time. And this is very right.


Another great feature, that makes our live easier is Set Root method and Hot Path marking. Now, once, you found the root of your application, you're able to "hide" unnecessary nodes (in most cases, those are system calls) and then mark the critical path (from performance point of view) in your call tree. You also can find all modules and functions, called selected method.


Another feature of new performance analysis tool is ability to compare your test run samples.


Very very cool tool, however it still too complicated for average user to understand what all those numbers mean, even with handy new Noise Reduction filters 🙂


Now you, probably, know what the problem with CarKiosk.exe application. You do not know what is it? Come and see at Developer Academy II at DEV 411.

הוסף תגובה
facebook linkedin twitter email

להגיב על Greg Young לבטל

האימייל לא יוצג באתר. שדות החובה מסומנים *

תגובה אחת

  1. Greg Young20 בנובמבר 2007 ב 23:07

    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 …