Applies to AQtime 8.71, last modified on December 5, 2018

The following sections describe the specifics of profiling managed applications in AQtime:


  • AQtime Standard for Embarcadero RAD Studio does not support profiling of .NET applications. It is available in AQtime Pro only.

    If you have not purchased AQtime Pro yet, you can order it now. Visit our Web site to learn more about differences between AQtime Standard for Embarcadero RAD Studio and AQtime Pro.

  • Due to certain security reasons, AQtime cannot profile those .NET applications that reside on another computer. Profiling of these applications causes an exception that occurs within the application code due to .NET Framework security. To profile these applications, launch AQtime on the computer where the application is located.

  • If you install AQtime for a single user account, you will not be able to profile .NET applications that run under another user account.

    Note: Both specifics concern profilers that launch your application. They are not applied to profilers that analyze your code statically.
  • AQtime does not trace exceptions that occur in console applications created for .NET Framework ver. 1.0 and 1.1.

  • AQtime currently cannot track the use of Windows resources that are called from .NET applications via P/Invoke. For more information on this, see the Using Resource Profiler With .NET Applications.

Searching for Memory Leaks

Since .NET Runtime releases all the objects when the application is closed, the profiling results that are typically generated after the application is terminated do not contain any significant information. That is why you need to monitor the use of objects and memory blocks during the application run. For more information, see Allocation Profiler - Analyzing .NET Applications.

Tracing Resource Allocation and Deallocation With the Resource Profiler

.NET applications work with Windows resources by using the mscorwks.dll assembly that contains functions that allocate and deallocate resources. In order for the Resource profiler to be able to track how your .NET application uses Windows resources, add the mscorwks.dll assembly to your AQtime project. See Using Resource Profiler With .NET Applications.

Measuring JIT Compilation and Garbage Collection Metrics

AQtime includes the Profile .NET runtime option that allows you to time JIT compilation and garbage collection routines. AQtime displays them as the <JIT compiler> and <Garbage collector> routines in the Report and Details panels. These fictitious routines are added to make it easier for you to analyze the time spent on JIT compilation and garbage collection.

For more information, see Pseudo-Routines in Profiling Results.

Different Results for the Same Function in Performance Profiling Results

If the Profile .NET runtime option is enabled, AQtime measures the time spent on executing the routine’s code and deducts the time spent on AQtime’s internal processes from the measured value. The resulting value is treated as the time spent on executing the routine’s own code. The mentioned approach can decrease resulting values and thus they may be different from those that were generated with the mentioned option disabled.

For example, suppose that the profiled application contains the following .NET routine:

void FooA();

If you profile this routine with the Profile .NET runtime option disabled, the results will contain the following values:

  • Time: 0.5 (sec.)
  • Time With Children: 0.5 (sec.)

If you profile the same routine with the Profile .NET runtime option enabled, the results will contain different values:

  • Time: 0 (sec.)
  • Time With Children: 0 (sec.)

The described behavior is caused by the fact that the profiled routine does not perform any calls or other actions (it just inserts a 500-millisecond delay) and when AQtime deducts the time spent on its internal processes (measuring the delay) from this time, the resulting value is really small and thus the Time column displays 0 (which differs from the initial result).

Note: Still, the .NET runtime uses complicated mechanisms and it usually instruments and optimizes functions before calling them. Because of that, if your application calls the same function one more time, the function may have already been instrumented and thus may affect the results. In other words, the results obtained for the second, third and so on call of the function might differ from the results obtained for the first call of the same function.

Default Class Constructor (.ctor Function)

You may notice .ctor functions in profiling results of .NET applications. These are default class constructors generated by the compiler. The debug information does not specify source lines for them. So, when you are try to examine their source code in AQtime’s Editor panel, it will show an approximate place where these constructors’ code may reside.

See Also

Profiling .NET Applications
Profiling .NET Applications - Overview

Highlight search results