Profiling and Dynamic Program Analysis in Rider

In this tutorial, you will make use of a Sudoku solver application. It reads a Sudoku puzzle from a text file, and then tries to solve it using a brute-force approach.
Internally, it iterates over every cell of a puzzle board, tries all combinations, and then verifies the solution.
A simple puzzle is solved in less than a second, more complex ones can take 10 to 20 seconds. In this tutorial, you will see if this can be optimized.
Profiling in Rider
Rider integrates with the dotTrace profiler to provide performance profiling of .NET applications. A profiling session can be started from the toolbar, or from the Run menu.
The profiling modes available depend on your operating system, and the .NET Framework version used in your application. A compatibility matrix is available in the web help.
Once the profiling is started, you will see the Performance Profiler tool window open. It shows the profiling controller, where you can get a snapshot, detach from the running application, and more. For the Sudoku solver, a snapshot is captured automatically after the application exits.
A profiling snapshot gives you the information required to start optimizing your application. It shows the call tree of method calls on all threads, and the top methods with the highest execution time.
What's in this tutorial?
In this tutorial, we used the profiler in Rider to investigate and optimize performance of the Sudoku solver application.
There are still some issues remaining, such as excessive allocations of the Cell type, which can be solved with making Cell a struct. Some small updates of the codebase already greatly improved performance!
Keep in mind that we used Debug builds to analyze the application. Release builds would include compiler optimizations and provide better performance of our application.
We have seen the different profiling modes in Rider: Sampling, Tracing, Line-by-Line, and Timeline. Sampling or Timeline profiling have low overhead, and come in handy to do most performance analysis on your application. Tracing and Line-by-Line provide accurate call numbers, but don't provide reliable call timings.
A good profiling workflow is cyclic: start with a baseline profiling session, make incremental changes, and analyze performance improvements (or regressions) as you go.
Dynamic Program Analysis (or DPA) analyzes your code automatically, every time it runs. It gives you feedback around memory usage and allocations, and shows the call stacks where most memory allocation is happening. The Heap Allocations viewer may help you figure out where hidden allocations and boxing occur in code.
Resources
- Performance Profiling in Rider www.jetbrains.com/help/rider/...
- Profiling Applications www.jetbrains.com/help/rider/...
- Profiling Unit Tests www.jetbrains.com/help/rider/...
- Dynamic Program Analysis (DPA) www.jetbrains.com/help/rider/...
- Heap Allocations Viewer plugin plugins.jetbrains.com/plugin/...
- List of fixes for issues found by DPA www.jetbrains.com/help/rider/...
- Sudoku solver application github.com/JetBrains/DPA-demo on GitHub
- dotTrace performance profiler www.jetbrains.com/profiler/
- dotMemory memory profiler www.jetbrains.com/dotmemory/

[@timurmalikov4033]

Is there any possibility to profile code on Mac M1?

[@JetBrainsTV]

You can profile your code on macOS with Apple silicon processors using dotTrace plugin integrated to Rider or using the dotTrace Command Line Tools.

[@jeyko666]

can you profile C++? can't find the option...

[@JetBrainsTV]

Profiling native applications is only supported on Windows. Find more details in this post:
blog.jetbrains.com/dotnet/2021/08/17/profiling-native-apps-in-dottrace/
If you encounter any difficulties or have any questions or feedback, do not hesitate to contact support (Help | Contact Support)

[@max8989max]

This accent is from Québec hehe :p