Code Profiling
• Code profiling is used to identify performance issues within .NET, native and mixed mode applications
(.OCXs, .EXEs and .DLLs).
- It is the act of collecting performance data (metrics) while an application or portion of an application is
running.
- The data can then analyzed to identify sections of code which cause performance bottlenecks.
• There are two forms of code profiling: Sampling and Instrumentation.
- Sampling is performed by the code profiler automatically, which pauses at specified intervals (clock
cycles, page faults, etc.) within the application, simulating a user interacting with the application.
- You give up control on the test because the code profile controls the pauses and performance gathering.
NOTE: It will be for the entire project, and yet may not test all the functions.
- Sampling is easier to set up. You do not need to inject code into specific methods, as you do in
Instrumentation.
- Instrumentation is more exact. It inserts Enter and Exit probes within the methods of the application.
- Instrumentation will cause the compiled code to be slightly larger but with more accurate results.
• The process typically involves the use of both Sampling and Instrumentation.
- First, you perform Sampling profiling to identify the assemblies causing performance bottlenecks.
- Afterward, if needed, you may perform Instrumentation analysis to identify the “slow” methods in
these assemblies.
- Instrumentation profiling creates a lot of data but gives you more specific information for the troubled
methods.
• You can create a new performance session based a currently open project or an existing .NET class
library (.DLL) or executable (.EXE).
- Click Tools – Performance Tools – New Performance Session.
Alternatively, you can use the Performance Wizard to have it based on a currently open project.
- You will see a new window pop up called the Performance Explorer.
- Right-click the Targets folder and add a binary (.OCX, .DLL, .EXE) file.
- You’ll see a window that looks like this:
• Across the top of the Performance Explorer window are buttons which can be used to:
- Use the Performance Wizard to create another Performance session
- Create a new empty Performance session
- Start the active performance profile session
- A dropdown menu to choose between Sampling and Instrumentation
- Stop the current performance profiling session
- Attach/Detach from a running process
• The two primary folders for each performance session are Targets and Reports.
- Targets are the binary files that the performance sessions are based on.
- The Reports folder holds the resulting reports from the tests.
• You can have multiple performance sessions in your current project.
- Like projects in a solution, the bold performance session is the active (selected) session.
- You can right-click one of the sessions and choose “Set as Current Session”.
• The results for a performance session are stored in a report file, which is a binary file with the name
ending with *.VSP.
- You can export these results into an XML or CSV file for analysis outside of Visual Studio.
- Here is an example of the results from a .NET Windows application getting the authors (via a .NET
Class Library) from the Pubs database and binding them to a DataGridView control.
• Code profiling is used to identify performance issues within .NET, native and mixed mode applications
(.OCXs, .EXEs and .DLLs).
- It is the act of collecting performance data (metrics) while an application or portion of an application is
running.
- The data can then analyzed to identify sections of code which cause performance bottlenecks.
• There are two forms of code profiling: Sampling and Instrumentation.
- Sampling is performed by the code profiler automatically, which pauses at specified intervals (clock
cycles, page faults, etc.) within the application, simulating a user interacting with the application.
- You give up control on the test because the code profile controls the pauses and performance gathering.
NOTE: It will be for the entire project, and yet may not test all the functions.
- Sampling is easier to set up. You do not need to inject code into specific methods, as you do in
Instrumentation.
- Instrumentation is more exact. It inserts Enter and Exit probes within the methods of the application.
- Instrumentation will cause the compiled code to be slightly larger but with more accurate results.
• The process typically involves the use of both Sampling and Instrumentation.
- First, you perform Sampling profiling to identify the assemblies causing performance bottlenecks.
- Afterward, if needed, you may perform Instrumentation analysis to identify the “slow” methods in
these assemblies.
- Instrumentation profiling creates a lot of data but gives you more specific information for the troubled
methods.
• You can create a new performance session based a currently open project or an existing .NET class
library (.DLL) or executable (.EXE).
- Click Tools – Performance Tools – New Performance Session.
Alternatively, you can use the Performance Wizard to have it based on a currently open project.
- You will see a new window pop up called the Performance Explorer.
- Right-click the Targets folder and add a binary (.OCX, .DLL, .EXE) file.
- You’ll see a window that looks like this:
• Across the top of the Performance Explorer window are buttons which can be used to:
- Use the Performance Wizard to create another Performance session
- Create a new empty Performance session
- Start the active performance profile session
- A dropdown menu to choose between Sampling and Instrumentation
- Stop the current performance profiling session
- Attach/Detach from a running process
• The two primary folders for each performance session are Targets and Reports.
- Targets are the binary files that the performance sessions are based on.
- The Reports folder holds the resulting reports from the tests.
• You can have multiple performance sessions in your current project.
- Like projects in a solution, the bold performance session is the active (selected) session.
- You can right-click one of the sessions and choose “Set as Current Session”.
• The results for a performance session are stored in a report file, which is a binary file with the name
ending with *.VSP.
- You can export these results into an XML or CSV file for analysis outside of Visual Studio.
- Here is an example of the results from a .NET Windows application getting the authors (via a .NET
Class Library) from the Pubs database and binding them to a DataGridView control.
Code Profiling
Table of Contents
Copyright (c) 2008. Intertech, Inc. All Rights Reserved. This information is to be used exclusively as an
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
online learning aid. Any attempts to copy, reproduce, or use for training is strictly prohibited.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Courseware
Training Resources
Tutorials