[Draft] Experiment with manual C# name reduction

[live1206]

Summary

Experiment with generated C# post-processing that avoids the remaining Roslyn Simplifier.ReduceAsync pass and instead performs targeted manual cleanup before writing generated files.

This is intentionally a draft/experiment branch for measuring output gaps and deciding which simplification categories are worth handling directly in the generator.

Current experiment

• Starts from latest main.
• Includes the qualified-name optimization baseline.
• Includes regression coverage for generated types with a member named System.
• Removes the remaining span-based Roslyn Simplifier.ReduceAsync call.
• Adds targeted manual reducers for:
  • global:: aliases in code and XML doc trivia
  • qualified type/member names, including nested generic type arguments
  • static/member access qualification where speculative binding proves safety
  • generic method type-argument inference cases
  • this. qualification where safe
  • generated parentheses/default/cast cleanup
  • predefined aliases such as Byte[] / Char[]
  • XML cref differences that Roslyn handles separately from normal code

Safety coverage added

Targeted GeneratedCodeWorkspace tests cover:

• two imported namespaces containing the same type name
• generated model shadowing a framework type
• current namespace type shadowing an imported type
• parameter/local/member name conflict with a type name
• XML cref handling separate from normal code
• aliases, generic names, customization types, and cast type arguments used before member access
• same-namespace static member reduction and conflict preservation
• generated parentheses/default/predefined-type shapes
• this. qualification reduction and local-name conflict preservation
• instance-member access preservation

Findings so far

Local Generate.ps1 succeeds. Generated test-project output now matches the checked-in baselines:

• initial no-Roslyn experiment: 801 generated files changed, 6329 added / 6329 removed lines
• after manual reducers: 0 generated test-project files changed
• global:: category reduced from ~4838 to 0 added occurrences

Validation

• Focused GeneratedCodeWorkspace safety tests passed.
• npm run build:generator passed.
• pwsh ./eng/scripts/Generate.ps1 passed.
• Final generated test-project diff: 0 files changed, 0 added, 0 removed.

Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@typespec/http-client-csharp@10885

commit: e4019d3

[github-actions]

No changes needing a change description found.

[live1206]

Network post-processing performance experiment results

Documenting the current experiment state before switching back to the Network MPG migration work.

Network generator-only timing

All runs used the saved Network generator inputs from sdk/network/Azure.ResourceManager.Network/{Configuration.json,tspCodeModel.json} and produced 3,542 .cs files.

Variant	Wall time	Roslyn/post-processing time	Result
main (ccc3f6004)	712.482s (~11m52s)	11m48.286s	Fastest baseline
PR #10846 / scoped simplifier (53124ea7f)	851.905s (~14m12s)	14m07.350s	~19.6% slower than main
This PR / manual no-Roslyn reducer (e4019d359)	1152.665s (~19m13s)	19m08.268s	~61.8% slower than main

Artifacts: /tmp/network-three-branch-20260604052728/.

Bounded parallelism follow-up

I also tried an env-var-gated bounded document-processing experiment (TYPESPEC_GENERATOR_POSTPROCESSING_PARALLELISM=16). The synthetic BenchmarkDotNet corpus looked promising, but real Network generation did not beat main:

Variant	Wall time	Roslyn/post-processing time	Files
main baseline	712s	11m48s	3542
manual branch + parallelism=16	722s	11m57s	3542
main + parallelism=16	733s	12m08s	3542

Artifacts: /tmp/network-parallelism16-20260604062933/ and /tmp/network-main-parallelism16-20260604064307/.

Conclusion

This PR is useful as an experiment, but the manual reducer approach is not currently a Network performance improvement. The bounded-parallelism experiment was removed from the working tree after it failed to beat main on Network.

Recommended next direction is deeper phase/document-size instrumentation around Roslyn workspace post-processing, then target reducing the number or size of documents that go through semantic simplification rather than replacing Roslyn simplification wholesale.