[http-client-csharp] Reduce Roslyn post-processing time (Simplifier.ReduceAsync dominates)

[JoshLove-msft]

Summary

The C# emitter (@typespec/http-client-csharp) spends roughly 70-80% of its CSharpGen.ExecuteAsync wall-clock time inside the Roslyn post-processing block (GeneratedCodeWorkspace.PostProcessAsync + ProcessDocument). The biggest single contributor is Simplifier.ReduceAsync. This issue tracks several concrete optimizations.

Measurements

Captured via the existing LoggingHelpers.LogElapsedTime markers + a temporary per-call Stopwatch around Simplifier.ReduceAsync in GeneratedCodeWorkspace.ProcessDocument:

Project	# generated files	Total ExecuteAsync	Roslyn block	Σ Simplifier.ReduceAsync CPU	Avg per file
Local/Sample-TypeSpec	138	9.10 s	7.53 s	148.4 s	~1.07 s/file
Spector payload/json-merge-patch	30	5.36 s	3.79 s	8.92 s	297 ms
Spector type/model/inheritance/nested-discriminator	38	5.12 s	3.95 s	15.66 s	412 ms
Spector type/enum/extensible	26	3.87 s	2.87 s	3.96 s	152 ms

Σ Reduce CPU vastly exceeds wall-clock because ProcessDocument runs in Task.WhenAll, but the Roslyn semantic-model lock serializes most of it, so reducing this CPU lowers wall-clock nearly proportionally.

Root causes

1. Whole-tree Simplifier.Annotation. GeneratedCodeWorkspace.UpdateProject (line ~93) and PostProcessor.MarkInternal (line ~343) call WithAdditionalAnnotations(Simplifier.Annotation) on the entire syntax root. This forces Simplifier.ReduceAsync to walk every node with a full semantic model and probe each reducer (CSharpAliasReducer, CSharpNameReducer, CSharpCastReducer, CSharpExtensionMethodReducer, CSharpParenthesesReducer).

2. Internalization re-annotates unnecessarily. MarkInternal only flips a public keyword to internal; nothing inside the type becomes reducible. The re-applied annotation triggers redundant work on the second ReduceAsync pass.

3. Duplicated InternalizeAsync + RemoveAsync. When UnreferencedTypesHandling = RemoveOrInternalize (the common case), both run in sequence. Each re-binds the compilation, re-walks every syntax tree, and re-runs SymbolFinder.FindReferencesAsync over every type. The Remove pass's reference graph is a strict superset of the Internalize pass's.

4. Sequential SymbolFinder.FindReferencesAsync in ReferenceMapBuilder.BuildPublicReferenceMapAsync / BuildAllReferenceMapAsync (sequential foreach … await over every declared symbol).

5. Per-node WithSyntaxRoot in InternalizeAsync (foreach (var (model, documentId) in nodesToInternalize) project = MarkInternal(...)) invalidates the compilation cache between every node.

6. GetSemanticModelAsync in ProcessDocument runs unconditionally, even when there are no rewriters and Simplifier.ReduceAsync is the only consumer.

Proposed optimizations (ranked by leverage)

1. Targeted Simplifier.Annotation. Annotate only the actual FQN nodes (AliasQualifiedNameSyntax rooted in global:: and their topmost QualifiedNameSyntax ancestor). Drop the root annotation in UpdateProject and MarkInternal. Expected to reduce Simplifier.ReduceAsync cost by an order of magnitude on large libraries.
2. Drop Simplifier.Annotation in MarkInternal entirely (no reducible content is introduced by an accessibility flip).
3. Skip Simplifier.ReduceAsync on documents with zero annotated nodes.
4. Merge InternalizeAsync + RemoveAsync into a single pass that builds one all-references map and derives both sets.
5. Parallelize SymbolFinder.FindReferencesAsync with Parallel.ForEachAsync and a ConcurrentDictionary-backed ReferenceMap.
6. Batch MarkInternal per document (one WithSyntaxRoot per document, not per node).
7. Skip GetSemanticModelAsync in ProcessDocument when no rewriters are registered and the document has no reducible annotations.
8. Long term: emit short type names + usings in CodeWriter.AppendType so Simplifier becomes a no-op and can be removed entirely (with the semantic-model fetch).

Reproduction

Add a Stopwatch around Simplifier.ReduceAsync in packages/http-client-csharp/generator/Microsoft.TypeSpec.Generator/src/PostProcessing/GeneratedCodeWorkspace.cs ProcessDocument and emit the cumulative time alongside the existing "Roslyn post processing complete" log line. Run npx tsp compile <spec> --trace @typespec/http-client-csharp --emit . --option @typespec/http-client-csharp.emitter-output-dir=<out> against any of the test projects above.

[JoshLove-msft]

Validation on a real Azure library (Azure.AI.Projects, ~884 generated files)

Measured with the new Simplifier.ReduceAsync tracing landed in csharp/simplifier-trace-and-cleanup. Run via Add-Debug-Profile.ps1 + dotnet <dll> <sdk> -g ScmCodeModelGenerator.

	Total	Roslyn block (post-process)	Simplifier.ReduceAsync Σ CPU
Baseline (main) trial 1	46.2 s	38.6 s	70 m 45 s (4245 s, 903 calls)
Baseline (main) trial 2	44.1 s	36.2 s	71 m 19 s (4279 s, 903 calls)
With #2 (drop redundant MarkInternal annotation) trial 1	40.2 s	32.5 s	73 m 26 s
With #2 trial 2	39.4 s	32.1 s	68 m 12 s

The Roslyn block is ~80% of total emit time on this library, and ~13% wall-clock improvement comes from #2 alone. The Σ Reduce CPU stays in the 68–73 min range — that 70+ minutes of CPU compressed into ~33 s of wall-clock confirms ReduceAsync is serialized on the Roslyn compilation lock.

New recommendation: emit using directives in the CodeWriter and skip Simplifier.ReduceAsync for fully-generated files

The targeted-annotation approach (option #1 in the original issue) was rejected because Simplifier is also doing paren / cast / extension-method reduction that the emitter currently relies on. A cleaner fix is to stop relying on Simplifier at all for files we generate end-to-end:

Why the emitter can do it faster than Roslyn
Roslyn's NameReducer walks every annotated node and asks the semantic model "what does this name resolve to in this current scope?" The semantic model takes the compilation lock — that's the source of the serialization. The emitter already has full type information on every CSharpType it writes; it doesn't need to resolve, it can decide at write time.

Sketch

1. In CodeWriter.AppendType, record type.Namespace in a per-file HashSet<string> and emit type.Name (no global::).
2. Detect simple-name collisions across the recorded set; for each colliding Name, keep one fully-qualified and don't add a using for it.
3. At file finalization, prepend a sorted using ...; block (System.* first) before the namespace.
4. Skip Simplifier.ReduceAsync for these files. Run it only on files merged with user customization (where partial user code might rely on it).

Why the other Simplifier passes don't matter for generated files

• ParenthesesReducer (the one that broke the targeted approach via (x = y);) — emitter controls every paren; just don't emit redundant ones.
• CastReducer — emitter knows the destination type at write time.
• ExtensionMethodReducer — emitter chooses call syntax.

Estimated upside on Azure.AI.Projects
With Simplifier.ReduceAsync removed for generated files, the Roslyn block drops to just Formatter (fast, syntactic) + PostProcessor (Internalize/Remove via SymbolFinder — orthogonal, addressed separately in this issue). Realistic target: ~5–10 s Roslyn block (down from ~33 s), i.e. ~25 s saved per emission, with proportional savings on every Azure data-plane library.

Caveats

• Need a careful collision detector: nested types, generics, types whose simple name shadows a member of the containing type or a System.* symbol already brought in.
• Customization-merged files still need Simplifier (or a documented contract).
• One-time golden-master refresh across every regenerated library.

Promoting this to the primary recommendation for this issue. The previously-listed options (SymbolFinder parallelization, merging Internalize+Remove, etc.) remain valid follow-ups but their wall-clock impact is dwarfed by the Simplifier work.

[JoshLove-msft]

Correction on the paren-reduction caveat above — point raised offline:

CodeWriter emits (expr) defensively because a ValueExpression doesn't know the precedence of its consumer; unconditionally dropping outer parens would produce wrong code in larger expressions and require a precedence-aware CodeWriter refactor.

Reframing the recommendation in three tiers:

• A. Skip NameReducer only; keep ParenthesesReducer. The 70 min of Reduce CPU is overwhelmingly the name reducer (semantic-model lookups serialized on the compilation lock). The paren reducer is mostly syntactic and cheap. Simplifier.ReduceAsync can be configured (via the OptionSet knobs SimplificationOptions.PreferIntrinsicPredefinedTypeKeyword* / a custom reducer set, or by invoking just the desired AbstractReducer directly) to skip name reduction. This is the recommended first PR — biggest wall-clock win, smallest blast radius, defensive parens still get cleaned up, no CodeWriter refactor.
• B. Skip Simplifier entirely, accept extra parens in generated source. Cheapest implementation; correct but cosmetically noisy. Probably DOA on review.
• C. Make CodeWriter precedence-aware (each ValueExpression declares precedence; consumer decides whether to wrap). Long-term "right" answer, eliminates the Roslyn dependency for name-emission and paren-emission alike. Significant refactor + golden-master refresh.

Suggested sequencing: A first (validates the upside and ships the win), C as a follow-up if/when we want to remove the Roslyn post-process step entirely.

[JoshLove-msft]

Negative result: targeted Simplifier annotation is slower, not faster

Tried prototyping the "annotate only nodes that need reducing" approach (option A from earlier comment): walk the tree, annotate only ParenthesizedExpression, AliasQualifiedName, QualifiedCref/TypeCref, name-chains rooted at an AliasQualifiedName, and MemberAccessExpression(this, ...) — leaving the document root un-annotated. Then call Simplifier.ReduceAsync as before.

Result on Azure.AI.Projects (~884 generated files):

	Total	Roslyn block	Σ Reduce CPU
Baseline (root annotation)	45 s	~36 s	~71 min
Targeted annotation	50 s	~41 s	~95 min

The targeted approach is structurally slower. Reading AbstractSimplificationService.ReduceAsync: it takes the annotated nodes, computes their spans, and runs the reducer once per span. With root annotation that's a single span covering the whole document and one reducer initialization (semantic-model snapshot, compilation lock acquire). With targeted annotation that's hundreds of small spans per document, each paying the per-span setup cost. The savings from visiting fewer name nodes are dwarfed by the multiplied initialization overhead.

Implication: there is no public-API way to make Simplifier.ReduceAsync cheaper without either:

1. Disabling individual reducers — Roslyn does not expose this. Would require either reflection into CSharpSimplificationService._reducers (fragile) or re-implementing Simplifier.ReduceAsync from scratch.
2. Pre-reducing the work so the reducer finds nothing to do — i.e. the CodeWriter-managed usings approach (formerly option C). The CodeWriter would emit short names + using directives directly; Simplifier.ReduceAsync would still run but NameReducer would short-circuit on each name (already-shortened, no semantic lookup triggered).

So: the path forward is option C, scoped initially as CodeWriter emits short names with a per-file usings set, falls back to global::Foo for collisions. The semantic-model cost is what dominates; cutting the name-reduction work at emit time is the only lever that matters.

Closing out the targeted-annotation direction.

[JoshLove-msft]

Update: Implemented per-file using directives + short type names in CodeWriter — massive win.

Branch: csharp/simplifier-trace-and-cleanup (commit 82df9b2cf).

What changed

CodeWriter now tracks every (namespace, headName) pair it has written as a global::-qualified type reference. In ToString(), it post-processes the body to shorten those occurrences to:

• bare HeadName when only one namespace owns the head name
• Namespace.HeadName when multiple emitted namespaces share the same head name (collision)

The using directives were already being emitted for every namespace touched, so we just stop writing the redundant global::Namespace. prefix.

Perf on Azure.AI.Projects (884 generated files)

	Total wall-clock	Roslyn block	Simplifier.ReduceAsync CPU
Baseline (HEAD before #2)	~45.2s	~37.4s	~71 min
With #2 only	~39.8s	~32.3s	~70 min
With short names	~28.2s	~25.5s	~32.4s

Simplifier.ReduceAsync CPU dropped from ~71 minutes to ~32 seconds — about 130×. Wall-clock dropped ~38%. Most of NameReducer's cost was the per-name semantic-model lookup; with names already short, the lookups become near-no-ops.

Output differences

Minor cosmetic only: <see cref="Foo.Method(JsonSerializerOptions?)"> doc comments lose the ? (Roslyn's cref-resolution previously normalized cref param types to match the signature; my pre-shortening means Simplifier no longer rewrites the cref). Compiles and resolves identically.

Will keep Simplifier.ReduceAsync for now — it still does cosmetic things (paren reduction, this.X, (T)null casts) and at 32s of CPU it's no longer the bottleneck.