How to profile the performance of a single .NET assembly (ANTS Profiler 3)

This article will explain how you can use ANTS Profiler 3 to limit the performance profiler to a single assembly. This can be a useful technique when you know that there are performance issues in a specific assembly or component. The benefits of setting up the profiler to profile just one assembly are that:

ANTS Profiler will run more quickly, as it is profiling less code
The results will only contain profiling data about methods in this assembly, which reduces the amount of information that you will have to review

Setting up the profiler

We will work through setting up ANTS Profiler to profile one component of a .NET desktop application. Exactly the same technique can be applied to all the other different types of .NET application, including ASP.NET web applications, and .NET Windows Services.

Let us imagine, for the sake of this article, that we have written a .NET desktop application called "CoolApp". The architecture of this simple application is shown in the diagram below. The user interface is contained in the main executable RedGate.CoolApp.exe. This executable uses two additional components that we have also written: RedGate.Library1.dll and RedGate.Library2.dll. All three .NET assemblies make extensive use of several .NET Framework libraries.

All the classes in RedGate.CoolApp.exe sit in the RedGate.CoolApp namespace.

All the classes in RedGate.Library1.dll sit in the namespace RedGate.Library1.

All the classes in RedGate.Library2.dll sit in the namespace RedGate.Library2.

application architecture diagram

When we run our "CoolApp", we quickly spot that there is a serious performance problem, and we know immediately that the problem must lie in Library1. We are keen to profile the performance of just this one dll.

We set up performance profiling of "CoolApp" in the usual fashion, using the ANTS Profiler 3 project wizard. The final screen of the wizard is the point at which we can customize the project to restrict profiling to just one library. We specify that we want to use a Custom filter to limit the areas of the application that will be profiled.

Custom filter screenshot

We edit the custom filter and specify that we are only interested in profiling a particular namespace, as shown below. In this case, we set up a filter that will cause ANTS Profiler to only profile methods that are part of the RedGate.Library1 namespace. This is exactly what we want, and we are now ready to start profiling.

Edit Custom Filter screenshot

We can now proceed with profiling in the usual fashion. However, when we get performance profiling results, either by taking a snapshot, or by closing down the application, they will only contain data about methods in RedGate.Library1.dll.

results screenshot

This approach massively reduces the number of methods that are profiled and shown in the results. Our task of hunting down bottlenecks is greatly simplified.

Additional comments

This simple technique can be applied to all other types of .NET application. You will need to find out the namespaces that are used by each component, but this is a straightforward task that can be accomplished quickly and easily using the Object browser in Visual Studio .NET.

Filtering in ANTS Profiler 3 can be made even more granular by specifying right down to the class or method name. For example, if we were concerned about the performance of a specific class, we could set up a filter to only profile that class only profile .NET methods that start with RedGate.Library1.MySpecialClass or, for a specific method, only profile .NET methods that start with RedGate.Library1.MySpecialClass.MyReallySlowMethod.

Sometimes there is not a one-to-one correspondence between namespaces and components. For example, the types exposed by the .NET Framework in the System.Collections.Generic namespace are shared between mscorlib.dll and System.dll. If we wanted to profile only the methods in System.dll, we would need to specify the namespace filters down to the class level, as above.

ANTS Profiler 3 does not present the user with a list of components that a particular application will use at runtime. This might seem like an obvious approach to make filtering easier. Although this would be relatively straightforward for .NET desktop applications, it is much less clear for profiling an ASP.NET web application specified by a single URL.

Memory profiling

You cannot specify any filtering of memory profiling when you set up a project. The reason for this is that all .NET memory objects are interlinked. However, once you have taken a snapshot of memory usage, you can filter the All objects tab to just show the objects allocated from a particular module.

Conclusion

This article illustrates how ANTS Profiler can be used in instances where you really need to focus on a performance bottleneck within a single .NET component.

Was this article helpful?

Search support