Find the Hot Path With dotnet-trace
Before we jump into optimising our application, we must make sure that the bottleneck we found is indeed an important one. If we optimise a part of the application that is seldomly used, we may waste a lot of time without improving the performance at all. The same is true for a part that is often used but faster than the real bottleneck somewhere else.
We can use the hot path to find the important spots in our application. But what is that and how do we find it?
What is the hot path?
The hot path (for performance optimization) refers to the specific sequence of code that is most frequently executed or has the highest runtime impact. It represents the "hottest" or most critical route through a program where performance bottlenecks significantly influence overall system efficiency. Unlike general code paths, the hot path handles the majority of processing, such as core loops, high-usage functions, or intensive computations.
Optimizing this path can involve reducing computational complexity, avoiding unnecessary operations, or improving data access patterns. Identifying and enhancing the hot path is crucial because small changes here have disproportionate large effects on overall performance.
Create a trace file
We can use the dotnet-trace command from the .Net diagnostic tools to create a trace file. But first we put everything in place so that we can record our application under heavy load – otherwise it will be hard to find the hot path.
- Start the application in release mode
- To warm it up, make a few clicks in the application
- Prepare the load test so that we can start it quickly – but do not start it now!
- Start dotnet-trace with this command:
- Start the load test
- Stop dotnet-trace (
CTRL-C)
Now we wait a bit until dotnet-trace finishes and creates the trace file.
Analyse the trace file in Visual Studio
We can open the trace file in Visual Studio. It will show us an overview with the top functions and the top insight:
The hot path in the overview is often too short to reach the interesting points. Therefore, we skip that for a moment. Instead, we go to “Open details” to dive into the more interesting parts.
Find the hot path
In the details of the report, we find the Current View drop down menu on the left side. There we select the option Call Tree what gives us a new view with additional buttons. Make sure that the option show the hot path is active and then click on * expand the hot path*. We now should see many expanded entries and we scroll the hot path down until we reach the end of it:
The method System.DateTime.get_Now() is not our code, but the GetRandomNumbers() method above is. If we click on the method, we can see how much time was spend and on which line:
It looks as if this single line of code is where the largest part of the time is spent in our application:
As the hot path showed us, it is not the line itself that takes the time – it is the method that gets called by this line. We can now open the application in Visual Studio and dive into the _waste.Waiting() method. Before we do that, let us explore a graphical way to find the time waster.
Explore the flame graph
In the Current View drop down menu we select Flame Graph. There we can see the call stack (the block on top calls the block below) and we see the time spend as the length of the block. We best scroll down to the end and see what is the widest and lowest block that is still part of our code.
As we saw in the call tree with the hot path, System.DateTime.get_Now() is the lowest and largest block. The method above is once more our GetRandomNumbers() method. If we click on it, the code for the method should show up and give us the same information as we got in the call tree.
The flame graph is an alternative form to report the same data as we got in the call tree. Depending on the amount of data we must look through, the flame graph may be the quicker way.
If you want to learn more about flame graphs, start with this article by Brendan Gregg.
Next
With the hot path we can figure out what parts of our application are in high demand. Tools like dotnet-trace and Visual Studio allow us to turn the performance tests into insights on which we then can act.
Next week we start improving our code and use BenchmarkDotNet to measure if we indeed made an improvement.



