[TrimmableTypeMap] Optimize build times

[simonrozsival]

Part of #10788

Track build-time optimization opportunities for the trimmable type map generation pipeline (GenerateTrimmableTypeMap task).

Current performance (PR #10924 benchmarks, MacBook M1)

Phase	Avg	P50	P95
Scan (8870 types)	235ms	224ms	319ms
Emit (typemap assemblies)	86ms	75ms	181ms
JCW (315 Java files)	766ms	409ms	3167ms
Total cold	1088ms	702ms
Total incremental (scan only)	221ms	215ms

Optimization opportunities

• Parallelize JCW source generation — each Java file generation is independent; running them in parallel could significantly reduce the JCW phase which dominates cold build time (suggested by @elinor-fung in [TrimmableTypeMap] Add GenerateTrimmableTypeMap MSBuild task and targets #10924 (comment))
• Parallelize assembly scanning — scanning assemblies for Java peers could be parallelized across assemblies (suggested by @elinor-fung in [TrimmableTypeMap] Add GenerateTrimmableTypeMap MSBuild task and targets #10924 (comment))
• Use MSBuild partial builds — replace the in-task timestamp checking with MSBuild native Inputs/Outputs 1-1 mapping so MSBuild only passes changed assemblies to the task, eliminating the stamp file (suggested by @jonathanpeppers in [TrimmableTypeMap] Add GenerateTrimmableTypeMap MSBuild task and targets #10924 (comment))
• Cache scan results across incremental builds — currently all assemblies are rescanned every build for cross-assembly type resolution; caching the scan index or adding a two-list Scan overload could skip unchanged assemblies
• Skip unchanged JCW files — avoid writing Java files whose content hasn't changed (attempted but read+compare cost negated savings; may be worth revisiting with content hashing)
• XDocument → XmlReader/XmlWriter for manifest generation — the manifest generator uses System.Xml.Linq (full DOM tree); explore streaming with XmlReader/XmlWriter to reduce allocations (suggested by @jonathanpeppers in [TrimmableTypeMap] Assembly-level manifest attribute scanning #11035)

[simonrozsival]

PR #10959 adds per-assembly acw-map.{AssemblyName}.txt files as a side-output of GenerateTrimmableTypeMap. When optimizing incremental builds (e.g., per-assembly Inputs/Outputs or the two-list Scan overload), the acw-map files should be included in the incrementality story:

• If an assembly is unchanged and its scan is skipped, the per-assembly acw-map file should also be preserved (not regenerated)
• AcwMapWriter.WriteToFile already does content comparison to avoid unnecessary timestamp updates, but skipping the write entirely (when the scan is skipped) would be even better
• The _MergeAcwMaps target uses Inputs/Outputs on the per-assembly files, so it will automatically skip if no acw-map file was touched

Adding this as a consideration item for the incremental build optimization work.

[simonrozsival]

Additional optimization: XDocument → XmlReader/XmlWriter for manifest generation

The manifest generator currently uses System.Xml.Linq (XDocument/XElement) which builds a full DOM tree in memory. For forward-only XML operations (e.g., reading the template manifest, writing the final output), XmlReader/XmlWriter would be more efficient — streaming and allocation-free.

Challenge: The current manifest generation requires read-modify-write semantics (load template → query existing elements for dedup → add new elements → save). This inherently needs a DOM. A pure XmlReader/XmlWriter approach would require building a custom in-memory model or restructuring the merge logic into a single streaming pass.

Potential approach:

• Read template with XmlReader, build a lightweight custom model (just element names + attributes for dedup)
• Generate new elements directly
• Write everything with XmlWriter in a single pass

Raised by @jonathanpeppers in #11035 (review)

[simonrozsival]

Follow-up from PR #11037: we prototyped broader incremental invalidation for _GenerateTrimmableTypeMap by hashing manifest-affecting MSBuild properties into an inputs cache file, but we are deferring that change to this issue to keep the manifest-rooting PR focused. If we pick this up here later, commit e9d0850 has a starting point for the approach.

[simonrozsival]

Split trimmable typemap generation into per-assembly MSBuild tasks for incremental builds

Problem

The trimmable typemap generator runs as a single monolithic MSBuild task (GenerateTrimmableTypeMap) that takes all assemblies, scans them sequentially, and produces all typemap DLLs in one invocation. This means any assembly change triggers a full regeneration of every typemap DLL — even if only one app assembly was modified. For Debug inner-loop builds, this is unnecessarily slow.

Proposed design

Core idea

Split the monolithic task into per-assembly invocations. Each invocation scans one input assembly (with reference assemblies available for type hierarchy resolution) and produces one typemap DLL. A downstream task generates the entry-point assembly.

The granularity depends on configuration:

• Debug: one assembly per task invocation → maximum incremental build granularity
• Release: all assemblies in one invocation → shared typemap universe with cross-assembly alias merging

Task 1: GenerateTypeMapUnit

Invoked once per "unit" of assemblies.

• Input assemblies: the assemblies to scan for Java peer types (one in Debug, all in Release)
• Reference assemblies: other assemblies needed only for resolving base type hierarchies, interface implementations, and activation constructors — loaded lazily, only when TryResolveType encounters a cache miss
• Output: one typemap DLL + JCW Java sources
• Cross-assembly alias merging happens within the unit (irrelevant for single-assembly Debug units; handles shared universe in Release)

Task 2: GenerateEntryPointTypeMap

Invoked once after all unit tasks complete.

• Input: list of per-unit typemap DLL names
• Output: _Microsoft.Android.TypeMaps.dll (entry-point assembly with TypeMapLoader.Initialize())
• For Debug: aggregates all per-assembly typemap references
• For Release: minimal — the single unit already produced the complete typemap

Debug vs Release flow

Debug (per-assembly units):

[Assembly A] ──Task 1──→ _A.TypeMap.dll
[Assembly B] ──Task 1──→ _B.TypeMap.dll ──Task 2──→ _Microsoft.Android.TypeMaps.dll
[Assembly C] ──Task 1──→ _C.TypeMap.dll (aggregates references)

Release (single unit):

[All assemblies] ──Task 1──→ typemap DLLs ──Task 2──→ _Microsoft.Android.TypeMaps.dll
 (alias merging here) (just entry point)

Incremental builds via assembly dependency graph

For MSBuild Inputs/Outputs to give precise incrementality, each unit task needs to know exactly which assemblies could affect its output — not just the input assembly, but every transitive dependency that could contribute Java peer types.

Pre-task: ComputeTypeMapDependencies

A lightweight pre-task reads each assembly's AssemblyRef metadata table (System.Reflection.Metadata, microseconds per assembly) and builds the transitive dependency graph.

Assembly A:
 AssemblyRef: A → Mono.Android, A → MyLibrary, A → System.Runtime
 Mono.Android → Java.Interop, Mono.Android → System.Runtime
 MyLibrary → Mono.Android

 Full transitive closure: {Mono.Android, Java.Interop, MyLibrary, System.Runtime}

Pruning: only Java-peer-bearing assemblies matter

An assembly can only contain Java peer types ([Register], [JniTypeSignature]) if it references Mono.Android or Java.Interop (directly or transitively). Assemblies like System.Runtime, System.Text.Json, etc. can never affect the typemap. The pre-task prunes the dependency graph by checking AssemblyRef entries — if an assembly's transitive closure doesn't include Mono.Android or Java.Interop, it's excluded from the dependency set.

Pruned dependency set for A: {Mono.Android, Java.Interop, MyLibrary}
(System.Runtime excluded — no path to Mono.Android or Java.Interop)

MSBuild integration

<!-- Fast pre-task: read AssemblyRef tables, build dependency graph -->
<ComputeTypeMapDependencies
 Assemblies="@(ResolvedAssemblies)">
 <Output TaskParameter="PerAssemblyDependencies" ItemName="_TypeMapInput" />
</ComputeTypeMapDependencies>

<!-- Per-unit typemap generation with precise Inputs -->
<GenerateTypeMapUnit
 InputAssembly="%(_TypeMapInput.Identity)"
 ReferenceAssemblies="%(_TypeMapInput.Dependencies)"
 Inputs="%(_TypeMapInput.Identity);%(_TypeMapInput.Dependencies)"
 Outputs="$(IntermediateOutputPath)typemaps\_%(_TypeMapInput.Filename).TypeMap.dll" />

<!-- Entry-point assembly -->
<GenerateEntryPointTypeMap
 PerUnitTypeMapDlls="@(_GeneratedTypeMapDlls)"
 OutputPath="$(IntermediateOutputPath)typemaps\_Microsoft.Android.TypeMaps.dll" />

Incrementality in practice

During typical inner-loop development:

• Developer changes MyApp.dll → only _MyApp.TypeMap.dll is rebuilt
• Mono.Android.dll, Java.Interop.dll, library DLLs are all stable → their typemap DLLs are untouched
• Entry-point assembly regeneration is cheap (just emits references to per-assembly DLLs)

On SDK/NuGet update:

• Mono.Android.dll changes → all typemaps that transitively depend on it are rebuilt
• This is correct and expected — base type hierarchies may have changed

Lazy reference assembly loading

The scanner (JavaPeerScanner) currently calls AssemblyIndex.Create for every assembly upfront, eagerly building full metadata indices. When scanning a single input assembly, most reference assemblies are never touched — the scanner only reads them when walking inheritance chains or resolving interfaces.

Reference assemblies should be indexed on demand — only when TryResolveType encounters a cache miss for an assembly name in the reference set. This reduces per-task memory and startup time, especially for app assemblies with shallow inheritance hierarchies.

Considerations

• JCW generation is already per-peer and moves naturally into Task 1
• Manifest generation needs the full peer list — should be a separate task or part of Task 2
• Global passes (manifest rooting, deferred registration propagation) need the full peer list in Release; in Debug, they're scoped to the unit's peers + resolved references
• ComputeTypeMapDependencies output can itself be cached — only recompute when the set of input assemblies changes

Scope

Optimization and refactoring. No behavioral changes to the generated typemaps or runtime behavior.