Pathological decompilation time on large ANTLR3-generated lexer classes (100s+ for a single type)
Performance finding from a full nuget.org catalog sweep with TestTools/nugetfuzz.cs (separate category from the resolution artifacts in #4092/#4093): decompiling a single ANTLR3-generated lexer class can take minutes, which trips the sweep's 60s-per-type budget.
Witnesses (the only 3 timeouts in ~4300 packages):
| package | assembly / type |
|---|---|
code2xml 3.4.1.107 |
Code2Xml.Core.dll / Code2Xml.Core.Generators.ANTLRv3.Java.JavaLexer |
code2xml.languages.java 1.0.0.10 |
Code2Xml.Languages.Java.dll / JavaLexer |
code2xml.languages.javascript 1.0.0.7 |
Code2Xml.Languages.JavaScript.dll / JavaScriptLexer |
Measurement. Standalone repro on the first witness:
ilspycmd Code2Xml.Core.dll -t Code2Xml.Core.Generators.ANTLRv3.Java.JavaLexer > /dev/null
real 1m45s (Debug build, Linux x64; completes, does not hang)The classes are ANTLR3 code generator output: hundreds of mT__nn/DFA methods plus very large generated methods and initializers. All other 4300+ swept packages, including 6000+-type assemblies, stayed well under the budget, so this is a pathological case rather than general slowness.
Status. Reproduces identically on current master and on the infer-type branch (PR #4090) - not a regression, a long-standing hot spot. Filed so the pathological case is on record with a concrete repro; profiling which transform dominates is the natural next step.
Filed by an AI agent (Claude, claude-fable-5, Claude Code) on behalf of @siegfriedpammer; measured on 2026-08-31.
Source: icsharpcode/ILSpy