ILSpy slow analysis version 7.1 versus 2.4

[Doug-Becker]

I had been happily using ILSpy version 2.4 for several years and never felt a strong reason to upgrade. Recently we changed the compiler we use to build our .NET Framework 4.8 assemblies and ILSpy 2.4 throws exceptions and crashes when decompiling certain assemblies.

So I upgraded to ILSpy 7.1, and while it seems to solve the crashing problems, it is incredibly slow when running an analysis. On ILSpy 2.4, analyses (for example, a "used by" analysis on a type or method) would complete in 1-2 seconds. On IlSpy 7.1, they are taking tens of minutes (not an exaggeration). This makes ILSpy effectively useless for me.

CPU usage during this wait is low (<10%) when running an analysis. There seems to be no major disk activity. There seems to be only one thread using CPU during this time (but even if it used all cores, the performance would not be close to the ILSpy 2.4)

Possibly a factor for this is that I have 6500+ assemblies loaded (as our system is huge). But ILSpy 2.4 handled this without a problem.

I haven't found any complaints about this in any web search, so I'm a bit puzzled why I am seeing this. I would have thought that such a dramatic loss of performance would have been noted by somebody. I realize that it's been a very long time since ILSpy 2.4, and the code has changed significantly since then, so I don't have much hope that anyone could easily point to why this has happened. But I'm hoping that someone could suggest a possible mitigation or at least have a theory to what might be causing this.

[siegfriedpammer]

I am very sorry to hear this, as ILSpy 4.0 and later should perform better than ILSpy 2.x in terms of memory usage, as we are no longer using Mono.Cecil and have removed one extra layer from our object model (so that's two layers less in total).

Please note that, decompilation speed might be a bit slower compared to 2.x in some cases, as we now use a very structured approach. The new decompiler engine performs much more work to produce correct method calls and member accesses, as it takes all available type information and conversions into account. Whereas the old engine only did some kind of "hand-waving" approximation when it comes to conversions.

The analysis engine was rewritten from scratch, so it is definitely possible that there are some things we can improve in that area. Not sure how we could go about analyzing this performance problem, as it depends on the amount and structure of assemblies. Is this reproducible, if you use all assemblies in your GAC in a single assembly list?

[siegfriedpammer]

First analysis on my computer:

633 Assemblies
[mscorlib]System.Object.Equals(object) Used By
ILSpy 2.4: 5.42s 1788 results
ILSpy master (7.2): 88.86s 1472 results

will investigate further

[siegfriedpammer]

I have created #2594 to track this. Let's continue the discussion there. Thanks!