The Ultimate .NET Experiment – open source project

Tune screenshot

I would like to present you a new tool I’ve started to work on recently. I’ve called it The Ultimate .NET Experiment (Tune) as its purpose is to learn .NET internals and performance tuning by experiments with C# code. As it is currently in very early 0.2 version, it can be treated as Proof Of Concept with many, many features still missing. But it is usable enough to have some fun with it already.

The main way of working with this tool is as follows:

  • write a sample, valid C# script which contains at least one class with public method taking a single string parameter. It will be executed by hitting Run button. This script can contain as many additional methods and classes as you wish. Just remember that first public method from the first public class will be executed (with single parameter taken from the input box below the script). You may also choose whether you want to build in Debug or Release mode (note: currently it is only x64 bit compilation).
  • after clicking Run button, the script will be compiled and executed. Additionally, it will be decompiled both to IL (Intermediate Language) and assembly code in the corresponding tab.
  • all the time Tune is running (including time during script execution) a graph with GC data is being drawn. It shows information about generation sizes and GC occurrences (as vertical lines with the number below showing which generation has been triggered).

In future, Tune will contain a much more sophisticated ETW-based analysis of the script run which will be also executed separately from the main application. I plan also to integrate it with BenchmarkDotNet.

Overall architecture

Tune is built from a few very interesting pieces, which will be probably much more clearer to show on the following diagram than to describe in words:

Tune architecture

As you can see, it is using parts of SharpDevelop (ICSharpCode) and Mono.Cecil libraries to decompile IL. To decompile into ASM it is using ClrMd to find method address location in the memory and then use SharpDisasm (which is a libudis86 C library port). It additionally uses dbghelp.dll to resolve native symbols. ETW data are being processed by the TraceEvent library.

Example usages

What can we do with Tune? To start, you can load three predefined scripts under File menu. In example 1 we can see how Echoer.Write ASM code look if Test is a class (including calling JIT_TrialAllocSFastMP_InlineGetThread object allocation):

Tune Example 1

And how it looks if Test is a struct (which shows an extraordinary level of optimization done by JIT as Write becomes only single mov assembly instruction!):

Tune example 2

Example 2 shows nice JIT optimization in which Write does not call Helper but jumps to it directly (and be invited to see how this code looks if Container<T> is a struct). To resolve addresses which are not part of jmp/call instruction you can use additional context menu:

Tune example 3

Example 3 shows ETW data (GC utilization) during long script execution:

Tune example 4

Building Tune

If you want to start your own experiments you can grab Tune from its github repository. Building requires Debugging Tools for Windows to be installed on your machine (to get symsrv.dll and dbghelp.dll). Currently, it depends also on DevExpress controls which I plan to remove soon.  If you do not want to install trial of DevExpress to build Tune, you may download compiled program:

Have fun!

Feel free to play around with Tune, comment here or submit any issues and ideas on Github. I would also like to point to site which was a great inspiration (and code) source for me in parts regarding assembly decompilation.

Leave a Reply

Your email address will not be published. Required fields are marked *