Make the invocation-based analyzers 15-35x faster

[petrikero]

What this speeds up

Twelve of the sixteen analyzers register on SyntaxKind.InvocationExpression and call GetSymbolInfo() as their first statement. That binds every call site in the compilation before discovering that the method is not one of the few the rule matches. On a large tree that is seconds of CPU per analyzer to answer "no".

Akka.Analyzers self-time, measured with ReportAnalyzer=true:

Target	Akka.Analyzers self-time
Akka.Tests	15.83s → 1.01s	−93.6%
Akka.Streams	7.55s → 0.53s	−92.9%
a ~150k-line Akka.NET server codebase	24.40s → 0.70s	−97.1%

Per rule, the six heaviest go from seconds to milliseconds — on Akka.Tests: AK1002 4.488s → 0.013s, AK1006 2.099s → 0.003s, AK2005 2.034s → 0.002s, AK1008 2.012s → 0.199s, AK2004 1.925s → 0.068s, AK2003 1.808s → 0.036s.

Measured by injecting each build of the analyzer into a real build — one project per run, Rebuild, shared compilation off, ABBA-ordered, min of 9. The effect is far outside the measurement error: the per-iteration samples do not overlap at all (e.g. Akka.Tests: dev 15.8–30.4s across nine runs, branch 1.0–2.1s).

How

The invoked method's simple name is available syntactically and rejects nearly every call site, so check it first.

• InvokedSimpleName(), MethodNames() and CouldInvokeAnyOf() in CodeAnalysisExtensions. The name set is built once per compilation from the reference symbols each analyzer already resolves, so it tracks those automatically; AK2000 and AK2001 match a single literal name instead.
• All twelve get the pre-filter, and their reference-symbol lookups move out of the per-node action. The lookups that cost the most: AK1006 can skip registration entirely when Akka.Persistence is absent, and its Persist.AddRange(PersistAsync) allocated an ImmutableArray per call site; AK2007's GetAllAggregateMethods() built a ten-element List per call site; AK1007 rebuilt two arrays per call site; AK2001, AK2003, AK2004 and AK2005 each called GetTypeByMetadataName per call site.
• AK1002 also moves its Parent is not AwaitExpressionSyntax test first: pure syntax, and it discards almost everything.
• AK1004 was the worst offender overall — before binding the invocation it resolved the enclosing class symbol, for every call site in the compilation.

The pre-filter is deliberately conservative (CouldInvoke, not DoesInvoke). It sits in front of the existing symbol comparisons, which are unchanged, so it can only skip nodes those comparisons would have rejected.

The four analyzers not registered on InvocationExpression — AK1000, AK1005, AK2002, AK2006 — are untouched.

Testing

No behaviour change intended, and no test changes: the existing suite is the correctness claim. Akka.Analyzers.Tests passes 329/331 with the 2 pre-existing skips.

Every benchmark run above also compared the AK#### diagnostics emitted by the two builds; they were identical in all of them. That is the check that matters most here, since a pre-filter bug surfaces as a silently missing diagnostic rather than a failure.

For reviewers

The one way this regresses is a call syntax that InvokedSimpleName() returns null for but the old code would have flagged. It handles a.Foo(), a?.Foo(), Foo() and Foo<T>(); everything else — Foo()(), x[0](), parenthesized method groups — binds to a delegate's Invoke rather than a target method, so the symbol comparison rejected those already.

If you reproduce the benchmark, note that a project which already gets Akka.Analyzers from a PackageReference will silently shadow an injected same-named DLL: the SDK drops the duplicate and csc loads the NuGet copy for both variants, which produces a very convincing null result. Check the analyzer version in the ReportAnalyzer output matches the build you think you are measuring.

---

Disclaimer: drafted with AI assistance, reviewed by me. All numbers above are real measurements from actual builds.