perf(strawberry-shake): format single-file output per namespace

[cliedeman]

Hotspot

With SingleCodeFile=true (the default), CSharpGenerator.GenerateSingleCSharpDocument built one giant CompilationUnit of every generated type and called compilationUnit.NormalizeWhitespace(elasticTrivia: true) on the whole tree. On the ILOPS operation set this was the dominant cost of code generation and scaled super-linearly:

• N=200 ops: generate ~88 s
• N=275 ops: generate ~182 s

The single huge tree was also the out-of-memory source for the full client.

Instrumenting the method showed two distinct super-linear costs, both inside it:

1. Building the namespace tree. Types were added to the namespace one at a time (namespaceDeclaration.AddMembers(typeDeclaration) in a loop). Each call on the immutable Roslyn node copies the growing member list, so a namespace with tens of thousands of types is quadratic. This client puts ~34k types in a single namespace, and this step alone was ~27 s at N=200.
2. Whole-tree NormalizeWhitespace over the multi-namespace tree (~13 s at N=200).

Approach

Output-identical reformatting (no behaviour change to the emitted source):

• Collect each namespace's members and set them once with WithMembers(List(...)) instead of repeated AddMembers. Namespace construction becomes linear (this removed the larger of the two costs).
• Normalize each namespace declaration on its own and join the pieces with the same blank-line separator the whole-tree normalizer emits between top-level namespace members (one line ending to close the previous namespace's brace, then one blank line). We never materialize one tree for the whole client.

A standalone namespace declaration normalizes with no leading or trailing trivia, so the joined text reconstructs the whole-tree output exactly. Normalizing each namespace as a real Roslyn subtree (rather than re-indenting per-type strings) is what makes this byte-identical: it preserves the normalizer's own handling of nested constructs, in particular preprocessor directives (#if NETCOREAPP3_1_OR_GREATER in the generated OperationDocument types), which the normalizer places in a way that a naive per-type re-indent cannot reproduce.

Output impact

Byte-identical. No snapshots change. All 189 generator and integration snapshot tests in CodeGeneration.CSharp.Tests pass unchanged (1 skipped), including every full-client *Test.Client.cs integration snapshot.

A per-type normalize was prototyped and measured (it would push the remaining normalize cost to linear and lower peak memory further), but it changes the emitted text for types containing preprocessor directives, so it was rejected in favour of the byte-identical per-namespace approach.

Before / after

generate ms on the ILOPS op set (warm, schema reused):

N (ops)	before	after	speedup
200	88,315 ms	~21,600 ms	~4.1x
275	181,956 ms	~40,000 ms	~4.6x

N=275 now completes reliably; the single-huge-tree OOM source is gone (no client-sized tree is ever built).

Relates to #17

— Claude
🤖 Generated with Claude Code