Welcome to MSDN Blogs Sign in | Join | Help

Tip: VS2008 - Understanding Performance Targets

default_wizard_output_slnexplorer

If you have a solution that contains multiple projects it is important to know what the 'Targets' group in the Performance Explorer is used for. The PeopleTrax solution shown on the right has 4 projects, with 3 of them compiling to managed DLLs and 1 compiling to an executable.

After running the Performance Wizard to create a Performance Session the Performance Explorer contains a single target as shown below.

default_wizard_output_perfexplorer 

Only the project that compiles to an executable is listed in the 'Targets' folder (for other project types like websites it would include the default launch project). What about the other 3 projects? As this tip explains, it depends upon the type of profiling you wish to do.

Sampling

With sampling there is no need to add the additional projects to your targets list. We do not modify assemblies when sampling and we will automatically attempt to collect data for any assemblies loaded by the PeopleTrax target. The only exception to this requirement is if you wish to collect data for multi-process scenarios and therefore need to launch multiple targets.

Instrumentation

For instrumentation, if you wish to collect data for the additional projects they should be added to your targets list as follows:

  1. In the Performance Explorer, right-click on the 'Targets' folder:
    add_target_project_rightclick
  2. Choose 'Add Target Project' to display a dialog:
    add_target_project_dialog 
  3. Select the assemblies you wish to collect Instrumentation data for and choose OK.

The selected projects will now be modified (instrumented) when you start profiling. You can selectively disable instrumentation for certain projects by right-clicking on the target and unchecking the 'Instrument' option.

targets_launchable_trace_properties_crop
Instrumentation properties for a specific target.

  [Colin Thomsen]

Posted by profiler | 0 Comments
Filed under: , , ,

Excluding Small Functions From Instrumentation

In Visual Studio 2008, we added a feature to exclude small functions from instrumentation.  A small function is a function that has very few instructions and makes no function calls (i.e. it’s a leaf).  The idea behind this feature is that small functions are unlikely to be significant in the overall profile of your application, so we can skip collecting data for them altogether to avoid the overhead of otherwise doing so.  This feature is meant to exclude property getters and setters, but it will also exclude very simple functions that are typically inlined anyway.

The first benefit of this feature is reduced instrumentation probe execution overhead.  Typically, small property getters and setters incur the time cost of executing two probes: the enter and exit probes.  The execution time of these probes dwarfs the execution time of the getter or setter itself.  To top it off, this cost is paid on every single property access which can be frequent.  By not instrumenting these property getters and setters, we can reduce execution overhead.

The second benefit is reduced profile data file (.vsp) size.  Fewer probes means less data collected.  If you’ve done instrumentation profiling before, you probably know that the data files can grow quickly.  Keeping file sizes smaller facilitates sharing and faster analysis.

The third benefit is reduced noise in your profile.  Since we don’t collect any data for these insignificant functions, they won’t even show up in your reports.  This is similar to, but independent of, the new noise reduction feature in VS2008.

With this feature enabled, it’s important to note that the time spent executing a small function does not just disappear.  Instead, the time gets attributed to the callers of the function excluded.  For example, if Foo calls SmallFunc, the exclusive time of SmallFunc when Foo called it is added to Foo’s exclusive time.  It’s as if the function was inlined at all of its call sites.

Small function exclusion is enabled by default which can, on occasion, cause issues.  Really simple projects such as a default C# console application or a default WCF service, are essentially infrastructure code in addition to (nearly) empty functions.  Because of this, profiling one of these default project types immediately after creation will typically yield “Error VSP1734 : File contains no data: ...” since nothing gets instrumented (they’re all small functions, after all).

You can disable small function exclusion by opening an instrumentation target’s properties, selecting the Instrumentation section, and unchecking “Exclude small functions from instrumentation”.  Each instrumentation target has its own value for this property.

target-props exclude-small-funcs

If you’re instrumenting your binaries on the command-line using vsinstr.exe, you can specify /excludesmallfuncs to exclude small functions from instrumentation.  The default command-line behavior is to instrument everything.

[Chris Schmich]

Posted by profiler | 0 Comments
Filed under: ,

Quick Tip: VS2008 - Compare Reports Quickly

While investigating a performance problem you may need to collect many Performance Reports and compare them. You can use the Performance Explorer to quickly compare two reports by:

  1. Selecting two reports.
  2. Right-clicking and choosing 'Compare Performance Reports...'
    comp_reports

The oldest report will be used for the 'Baseline' report and the other report will be used for the 'Comparison' report, as shown below:

comp_reports_2

[Colin Thomsen]

Posted by profiler | 1 Comments

What code path is allocating the most bytes for a type?

In Visual Studio 2008, we added the ability to quickly determine the most expensive call stack in your application.  In profiler parlance, the “most expensive call stack” is known as the “hot path”.  What do we mean by “expensive”?  “Expensive” is whatever measure you want it to be: number of samples in a function, time spent in a function, or even number of bytes or allocations in a function.

If you profile the managed memory usage of your application (also available in VS2008), you will get a new view in your profiling report called the Allocation View:

allocation-view

For each managed type allocated in your application, this view will show you the call stack where each allocation took place as well as the number of bytes and instances allocated in each function.

You can explore these call trees as you do normally, including using hot path to find the expensive allocation paths through your code for a specific type.  This is accessible through either the toolbar or the context menu by right-clicking on the function from where you want to start hot path:

allocation-hot-path-menu

In this example, we know we’re allocating about 741KB of memory for System.Drawing.Graphics objects.  Using hot path, we can quickly determine that the majority (67%)  of the bytes are being allocated in System.Drawing.Graphics.FromHwndInternal.  Because we do not control this code, we can look up the stack until we see code that we can change: MainForm.SetCell.  This would be a great place to begin investigation.

allocation-hot-path

It’s important to note that the allocation hot path is not the single function allocating the most bytes in your application (you can use the Function View for that).  Instead, it is the specific path through your code that is allocating the most bytes for a type.

[Chris Schmich]

Posted by profiler | 0 Comments

Very Quick Tip: Getting the most out of your screen for viewing call trees

I spend a lot of time in the profiler's Call Tree view when I use the profiler.  When you are really digging deep into the tree, screen real estate becomes a big issue.  There is one very simple Visual Studio trick that really helps out so you can get more of the call tree on the screen at one time without scrolling around.  Set the focus on the call tree view and hit Shift-Alt-Enter.  It will bring up a full screen view of just the document you are working on which makes it much easier to do the data analysis (especially on wide screen monitors).  This works in all VS documents. 

[Steve Carroll - scarroll]

Posted by profiler | 1 Comments
Filed under: , ,

Quick Tip: "Save Analyzed" for large VSP files

One cool new feature in the Visual Studio 2008 Profiler is the ability to take a large VSP file that has been analyzed once and save the report data into a VSPS file (Visual Studio Profiler Summary files).  Saving the analyzed data has several major benefits:

    1. The analyzed data is orders of magnitude smaller than the VSP file.  We've seen 4GB trace VSPs get compressed into less than 100K VSPS files.
    2. Because the data saved in the VSPS files has already been processed by our data analyzer, it will load up much faster. 
    3. Symbol data is automatically packed into the VSPS file.

VSPS files because of their small size, quick analysis, and saved symbols are perfect for use as saved baselines with the new performance comparison functionality in VS2008.  A best practice is to regularly save off VSPS files for your performance scenarios so you can look for performance regressions from one milestone to the next.

This feature is not particularly discoverable.  Here's a quick map of where to find it (highlighted in yellow):

SaveAnalyzed

One caveat: because the data has already been analyzed in the VSPS file, you can't use filters on VSPS files.

[Steve Carroll - scarroll]

Performance: Find Application Bottlenecks with Visual Studio Profiler

A couple of members of the profiler team recently wrote an article for msdn magazine, which describes how to use the Visual Studio 2008 profiler to improve the performance of an application. They examined a Mandelbrot fractal drawing program in some detail and isolated and fixed several performance problems in the code, speeding up program execution time approximately tenfold.

[colinth]

Posted by profiler | 2 Comments

Articles on new Visual Studio Team System 2008 profiler features

I’ve recently been working on a series of post on my blog about many of the cool new features that we are adding in Visual Studio Team System 2008 (codename Orcas). So I figured that I’d post a quick link here to all the articles that I’ve finished so far.

Collecting Performance Counter information with the Visual Studio Profiler

Pinpoint a performance issue using hotpath in Visual Studio 2008

The Visual Studio Profiler Data Collection Control Part 1: Excluding Application Startup Time

Comparing performance reports with the Visual Studio Team System Profiler

[ianhu]

S. Somasegar on new profiler features

S. Somasegar the VP of Developer Division has just put up a post on his weblog detailing some new profiler and debugger features up coming in VS 2008. Check out the article here.

[ianhu]

Posted by profiler | 1 Comments

Another welcome...

Chris Schmich, a former intern on our team, is now back in town and working full time on the profiler. He has a blog up and running as well, starting out with the Obligatory First Post.

 [ianhu]

Posted by profiler | 0 Comments

Welcoming Colin to the profiler team

We recently added a new team member here in profiler land and he’s up and kicking with a blog already. Check out Colin’s blog here for his first entry on basic profiler scenarios.

~Ian

Posted by profiler | 0 Comments
Filed under: ,

Introducing new Visual Studio Profiler Features in the Orcas Beta

Hey all, I'm rolling out a new series of articles about the new Visual Studio Team System Profiler features that will be included with the latest Orcas beta release. Check out the first article on comparison documents here.

 ~Ian

Posted by profiler | 1 Comments

New FAQs posted for the profiler and code coverage tools

I've just posted a couple of FAQs to answer the most common profiler and code coverage questions that I see on our Visual Studio Team System MSDN forums. Check them out below:

Visual Studio Team System 2005 Code Coverage Tool FAQ

Visual Studio Team System 2005 Profiler Tool FAQ

[ianhu]

Posted by profiler | 0 Comments

The Value of Team System to C++/Native Win32 developers

A common question asked of Team System developers is, "What does Team System offer me for my native code development?" Joc (the development lead on the Diagnostic team) just took the time to answer that question in the blog post below:

http://blogs.msdn.com/ms_joc/archive/2006/04/19/579277.aspx

 

[ianhu]

Posted by profiler | 0 Comments

Welcome John Lyon-Smith

John Lyon-Smith, a new hire for our team, has just started up his blog. Check out his first entry on counting bits.

Posted by profiler | 0 Comments
More Posts Next page »
 
Page view tracker