FC33 Visual Studio Decompilation, there seems to be a pause

My way of contributing to Open-Source Software is finding performance issues in them and send them suggestions. Now that I’m using Visual Studio 2022 Community Edition, I should help it to improve. When you click on go to definition, Visual Studio will try to decode IL assembly into source code, but there seems to be a pause. Let’s capture a trace, looking into it:

The Decompile method here is responsible for 29.1% of total allocations, mostly in isharpcode.decompiler. The interesting thing here is there are four LOH allocations: StringBuilder.ToString, and three string.Concat calls. The concatenation calls are strange. Let’s check source code:

The StringBuilder.ToString call is inside DecompileTypeAsString implementation:

The first stage of decompilation just translates source code into a syntax, the second stage walks the tree, generating source code into a StringWriter which has a StringBuilder inside.

Now we can replace four LOH string allocations with just one:

The code is just moving out StringWriter and append more strings to it afterwards. Source code: FrugalCafe/Posts/TestICSharpDecompiler.cs at master · ProfFrugal/FrugalCafe (github.com)

Here is another interesting stack:

Source code:

There are quite a few issues here:

1. indent is a constant string. Even if you want to generate it, you can just use new string(‘ ‘, s_identSize * 2), no need for StringBuilder.

2. StringBuilder.ToString is called twice at the end.

3. Most likely, the string fits on single line, so string.Split and StringBuilder are not needed.

In conclusion, there are lots of StringBuilder related performance issues, even in professional software.