Profiling Overview

Microsoft Silverlight will reach end of support after October 2021. Learn more.

Note:
This overview is intended to serve as an introduction to the profiling functionality that is available to Silverlight developers. For complete documentation on profiling, see Profiling (Unmanaged API Reference) in the MSDN Library.

A profiler is a tool that monitors the execution of another application. A common language runtime (CLR) profiler is a dynamic link library (DLL) that consists of functions that receive messages from, and send messages to, the CLR by using the profiling API. The profiler DLL is loaded by the CLR at run time.

Traditional profiling tools focus on measuring the execution of the application. That is, they measure the time that is spent in each function or the memory usage of the application over time. The profiling API targets a broader class of diagnostic tools such as code-coverage utilities and even advanced debugging aids. These uses are all diagnostic in nature. The profiling API not only measures but also monitors the execution of an application. For this reason, the profiling API should never be used by the application itself, and the application’s execution should not depend on (or be affected by) the profiler.

Profiling a CLR application requires more support than profiling conventionally compiled machine code. This is because the CLR introduces concepts such as application domains, garbage collection, managed exception handling, just-in-time (JIT) compilation of code (converting Microsoft intermediate language, or MSIL, code into native machine code), and similar features. Conventional profiling mechanisms cannot identify or provide useful information about these features. The profiling API provides this missing information efficiently, with minimal effect on the performance of the CLR and the profiled application.

JIT compilation at run time provides good opportunities for profiling. The profiling API enables a profiler to change the in-memory MSIL code stream for a routine before it is JIT-compiled. In this manner, the profiler can dynamically add instrumentation code to particular routines that need deeper investigation. Although this approach is possible in conventional scenarios, it is much easier to implement for the CLR by using the profiling API.

For complete documentation on writing a profiler for CLR applications, see Profiling (Unmanaged API Reference) in the MSDN Library.

For an overview of the differences between writing profilers for the .NET Framework version 4 and later and writing profilers for Silverlight 4 and later, see the entry Writing a Profiler for Silverlight 4 in the CLR Profiling API blog.

For more information about using profiling tools in Visual Studio, see the topics in the profiling tools section of the Visual Studio documentation.