Share via


Profiling API Capabilities

The profiling API provides information about a variety of events and actions that occur in the common language runtime (CLR). You can use this information to monitor the inner workings of processes and to analyze the peformance of your .NET Framework application.

Supported Features

The profiling API retrieves information about the following actions and events that occur in the CLR:

  • CLR startup and shutdown events.

  • Application domain creation and shutdown events.

  • Assembly loading and unloading events.

  • Module loading and unloading events.

  • COM vtable creation and destruction events.

  • Just-in-time (JIT) compilation and code-pitching events.

  • Class loading and unloading events.

  • Thread creation and destruction events.

  • Function entry and exit events.

  • Exceptions.

  • Transitions between managed and unmanaged code execution.

  • Transitions between different runtime contexts.

  • Information about runtime suspensions.

  • Information about the runtime memory heap and garbage collection activity.

The profiling API can be called from any (non-managed) COM-compatible language.

The API is efficient with regard to CPU and memory consumption. Profiling does not involve changes to the profiled application that are significant enough to cause misleading results.

The profiling API is useful to both sampling and non-sampling profilers. A sampling profiler inspects the profile at regular clock ticks, say, at 5 milliseconds apart. A non-sampling profiler is informed of an event synchronously with the thread that causes the event.

Unsupported Functionality

The profiling API does not support the following functionality:

  • Unmanaged code. The CLR profiling API works only for managed code. You must use conventional Win32 mechanisms to profile unmanaged code. However, the CLR profiler includes transition events to determine the boundaries between managed and unmanaged code.

  • Self-modifying applications. The profiling API does not support applications that modify their own code for purposes such as aspect-oriented programming.

  • Bounds checking. The profiling API does not provide the information that is required to check bounds. The CLR provides intrinsic support for bounds checking of all managed code.

  • Remote profiling. The CLR code profiler interfaces do not support remote profiling for the following reasons:

    • Remote profiling extends execution time. When you use the profiler interfaces, you must minimize execution time so that profiling results will not be unduly affected. This is especially true when execution performance is being monitored. However, remote profiling is not a limitation when the profiler interfaces are used to monitor memory usage or to obtain run-time information about stack frames, objects, and so on.

    • The CLR code profiler must register one or more callback interfaces with the runtime on the local computer on which the profiled application is running. This limits the ability to create a remote code profiler.

  • Profiling in production environments with high-availability requirements. The profiling API was created to support development-time diagnostics. It has not undergone the rigorous testing required to support production environments.

See Also

Concepts

Profiling in the .NET Framework

Profiling Overview