Avoid layout diagnostics allocations without listeners

[AdamEssenmacher]

Fixes layout diagnostics allocation churn in the no-consumer path.

In MAUI 10, IView.Measure / IView.Arrange could allocate on every call when System.Diagnostics.Metrics.Meter.IsSupported == true, even when no ActivityListener or MeterListener was consuming MAUI layout diagnostics. This change gates layout diagnostics work on actual consumers before constructing tags or instrumentation state:

• activity consumer: ActivitySource.HasListeners()
• metrics consumer: layout counter/histogram Enabled

The layout-specific instrumentation path now avoids the generic IDiagnosticInstrumentation stop path so the no-listener case avoids tag construction, struct boxing, and per-operation allocation.

Also adds a LayoutDiagnosticsBenchmarker covering single-view and layout-tree measure/arrange with no active diagnostics listener.

Benchmark command:

dotnet run --project src/Core/tests/Benchmarks/Core.Benchmarks.csproj -c Release -f net10.0 -- --filter "*LayoutDiagnosticsBenchmarker*" --job short

Results comparing the pre-patch merge base to this branch:

Benchmark	Pre Mean	Post Mean	Time Change	Pre Alloc	Post Alloc	Alloc Change
MeasureAndArrangeViewNoListener	106.983 ns	15.712 ns	-85.314%	376 B	0 B	-100.000%
MeasureAndArrangeTreeNoListener	155.880 ns	27.890 ns	-82.108%	392 B	0 B	-100.000%

Issues Fixed

Fixes #35473

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35475

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35475"

[dotnet-policy-service]

Hey there @@AdamEssenmacher! Thank you so much for your PR! Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[jfversluis]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 3 pipeline(s).

[kubaflo]

/review -b feature/regression-check -p android

[kubaflo]

It is cool! Could you please review the ai's suggestions, though?

[AdamEssenmacher]

It is cool! Could you please review the ai's suggestions, though?

I reviewed the AI suggestions and pushed a follow-up commit.

I kept the current PR approach rather than switching to one of the alternative candidates because the Stopwatch path is intentional: it lets metrics-only histogram listeners record layout durations even when there is no ActivityListener and StartActivity(...) would return null.

Changes made:

• Replaced the timestamp 0 sentinel with an explicit duration-started bool for measure and arrange.
• Hardened elapsed nanosecond conversion to return 0 for non-positive elapsed time and clamp overflow to int.MaxValue.
• Added CI-running unit tests for:
  • zero allocations on repeated measure/arrange with no diagnostics listeners
  • metrics-only measure/arrange duration recording without activity listeners
  • duration clamp and non-positive elapsed handling

Validated with:

dotnet test src/Core/tests/UnitTests/Core.UnitTests.csproj -f net10.0 --filter LayoutDiagnosticsTests

Result: 5 passed, 0 failed.

[kubaflo]

/review -b feature/regression-check -p ios

[kubaflo]

/review -b feature/regression-check -p ios

[MauiBot]

Expert Review — 7 findings

See inline comments for details.

[MauiBot]

[minor] Performance — recomputed scale factor — 1_000_000_000.0 / Stopwatch.Frequency is recomputed on every call. Stopwatch.Frequency is a runtime constant per process, but the JIT cannot fold the division because Frequency is a static property, not a const. Hoist into a private static readonly double s_tickToNanoseconds = 1_000_000_000.0 / Stopwatch.Frequency; to save a div per measure/arrange when durations are recorded. Pure win on the histogram-enabled hot path.

[MauiBot]

[minor] Performance — duplicated tagger walk — When both HasActivityListeners and IsArrangeEnabled are true, _diagnostics.GetTags(_view, ...) runs once in the constructor (for the Activity) and again here (for the metric). TagList is a stack struct but the tagger iteration still re-reads _taggers[] and re-invokes AddTags for every tagger. Consider caching the TagList as a field on the struct when the activity branch already produced it (cheap because the struct is on the stack and TagList copies in the tagger contract are already by-ref). Skip if you'd rather keep the struct slim — current cost only hits the dual-listener path. Same nit applies to LayoutMeasureInstrumentation.Dispose line 57.

[MauiBot]

[minor] Logic — recordDuration re-check is asymmetric with IsArrangeEnabled recovery — If IsArrangeDurationEnabled flips from false → true between ctor and Dispose, _metricsDurationStarted is false so we won't have a timestamp, and recordDuration is forced false (correct). However if IsArrangeEnabled flips false → true mid-call, the counter is recorded with duration=0 and the histogram is silently skipped — a one-sided race that produces a counter sample with no matching histogram sample. The window is tiny and the consequence is benign (slightly inconsistent metric snapshot), but worth a one-line comment so a future reader doesn't assume the symmetric check is intentional. Same applies to LayoutMeasureInstrumentation.Dispose line 48.

[MauiBot]

[moderate] Test determinism — strict-zero allocation assertion may be JIT-tier-flaky — 64 warmup iterations may be insufficient on .NET 8+ with tiered JIT enabled: rejit/PGO can recompile a method around iteration ~30–100 of the measurement loop and the rejit itself allocates onto the calling thread, which GC.GetAllocatedBytesForCurrentThread() will attribute to the loop. Recommend either (a) increase warmup to 1024+ to match the measurement count, (b) attribute the test with [MethodImpl(MethodImplOptions.NoInlining | MethodImplOptions.AggressiveOptimization)] on the measurement helper plus call it in warmup, or (c) call it twice and assert on the second run only. Today the test passes locally, but a CI agent under load or a future runtime change could flake without any product regression.

[MauiBot]

[minor] Test assertion is too weak — Assert.True(measurement >= 0) accepts a degenerate case where every nanosecond reading is 0. Given Stopwatch.GetTimestamp resolution is typically ≤100 ns and the test runs real measure/arrange, a value of exactly 0 would be suspicious. Consider asserting measurement >= 0 AND that at least one of the recorded samples is > 0 (when running multiple iterations) — or document explicitly that 0 is permitted because some platforms have low-resolution Stopwatch. The >= 0 bound is what GetElapsedNanoseconds guarantees so the assertion currently can't fail meaningfully.

[MauiBot]

[minor] API surface — HasActivityListeners duplicates ActivitySource.HasListeners() — Since the interface already exposes ActivitySource, callers can write diagnostics.ActivitySource.HasListeners() directly and skip widening the interface. Two reasons to keep the new member anyway, both valid: (a) tighter intent at the gate site, (b) easier mocking in unit tests. Suggest adding a one-line XML doc clarifying it's a hot-path gate so future readers don't treat it as redundant API.

[MauiBot]

[minor] AOT/trim & hot-path DI lookup — Every measure/arrange on every view pays a view.Handler?.MauiContext?.Services?.GetService<IDiagnosticsManager>() call (via GetMauiDiagnostics()). MS.DI's generic GetService<T> is fast (~tens of ns) but it's still a dictionary lookup on every layout pass, scaling with the visual tree. The benchmark (16 ns) suggests it's tolerable, but consider caching the resolved IDiagnosticsManager on the handler (or on MauiContext) as a follow-up — a single ref field read would be ~1 ns and remove the DI call from the per-view hot path entirely. Not blocking for this PR.

[kubaflo]

/review -b feature/regression-check -p ios

[kubaflo]

/review -b feature/regression-check -p ios

[MauiBot]

🤖 AI Summary

👋 @AdamEssenmacher — new AI review results are available. Please review the latest session below.

📊 Review Session — 4f9fb84 · Add layout diagnostics regression tests · 2026-05-21 23:55 UTC

🚦 Gate — Test Before & After Fix

Gate Result: ✅ PASSED

Platform: IOS · Base: main · Merge base: eb20ff6e

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🧪 LayoutDiagnosticsTests LayoutDiagnosticsTests	🛠️ BUILD ERROR	✅ PASS — 20s

🔴 Without fix — 🧪 LayoutDiagnosticsTests: 🛠️ BUILD ERROR · 32s

  Determining projects to restore...
  Restored /Users/cloudtest/vss/_work/1/s/src/Graphics/src/Graphics/Graphics.csproj (in 1.01 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/TestUtils/src/TestUtils/TestUtils.csproj (in 4.29 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Core/tests/UnitTests/Core.UnitTests.csproj (in 5.21 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Essentials/src/Essentials.csproj (in 5.5 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Core/src/Core.csproj (in 6.05 sec).
  Restored /Users/cloudtest/vss/_work/1/s/src/Controls/src/Core/Controls.Core.csproj (in 6.07 sec).
  1 of 7 projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14162406
  Graphics -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14162406
  Essentials -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14162406
  Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14162406
  Controls.Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  TestUtils -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/TestUtils/Debug/netstandard2.0/Microsoft.Maui.TestUtils.dll
/Users/cloudtest/vss/_work/1/s/src/Core/tests/UnitTests/Diagnostics/LayoutDiagnosticsTests.cs(97,53): error CS0117: 'LayoutDiagnosticMetrics' does not contain a definition for 'GetElapsedNanoseconds' [/Users/cloudtest/vss/_work/1/s/src/Core/tests/UnitTests/Core.UnitTests.csproj]
/Users/cloudtest/vss/_work/1/s/src/Core/tests/UnitTests/Diagnostics/LayoutDiagnosticsTests.cs(107,53): error CS0117: 'LayoutDiagnosticMetrics' does not contain a definition for 'GetElapsedNanoseconds' [/Users/cloudtest/vss/_work/1/s/src/Core/tests/UnitTests/Core.UnitTests.csproj]

🟢 With fix — 🧪 LayoutDiagnosticsTests: PASS ✅ · 20s

  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14162406
  Graphics -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14162406
  Essentials -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14162406
  Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.80-ci+azdo.14162406
  Controls.Core -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  TestUtils -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/TestUtils/Debug/netstandard2.0/Microsoft.Maui.TestUtils.dll
  Core.UnitTests -> /Users/cloudtest/vss/_work/1/s/artifacts/bin/Core.UnitTests/Debug/net10.0/Microsoft.Maui.UnitTests.dll
Test run for /Users/cloudtest/vss/_work/1/s/artifacts/bin/Core.UnitTests/Debug/net10.0/Microsoft.Maui.UnitTests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (arm64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.06]   Discovering: Microsoft.Maui.UnitTests
[xUnit.net 00:00:00.18]   Discovered:  Microsoft.Maui.UnitTests
[xUnit.net 00:00:00.19]   Starting:    Microsoft.Maui.UnitTests
[xUnit.net 00:00:00.26]   Finished:    Microsoft.Maui.UnitTests
  Passed DurationMetricsRecordWithoutActivityListeners(instrumentName: "maui.layout.measure_duration") [47 ms]
  Passed DurationMetricsRecordWithoutActivityListeners(instrumentName: "maui.layout.arrange_duration") [1 ms]
  Passed ElapsedNanosecondsClampsToIntMaxValue [1 ms]
  Passed MeasureAndArrangeDoNotAllocateWithoutListeners [5 ms]
  Passed ElapsedNanosecondsReturnsZeroForNonPositiveElapsedTime [< 1 ms]

Test Run Successful.
Total tests: 5
     Passed: 5
 Total time: 0.6117 Seconds

⚠️ Failure Details

• 🛠️ LayoutDiagnosticsTests without fix: build failed before tests could run
  • /Users/cloudtest/vss/_work/1/s/src/Core/tests/UnitTests/Diagnostics/LayoutDiagnosticsTests.cs(97,53): error CS0117: 'LayoutDiagnosticMetrics' does not contain a definition for 'GetElapsedNanoseconds' ...

📁 Fix files reverted (8 files)

• .gitignore
• eng/pipelines/ci-copilot.yml
• src/Core/src/Diagnostics/DiagnosticsManager.cs
• src/Core/src/Diagnostics/IDiagnosticsManager.cs
• src/Core/src/Diagnostics/Instrumentation/DiagnosticInstrumentation.cs
• src/Core/src/Diagnostics/Instrumentation/LayoutArrangeInstrumentation.cs
• src/Core/src/Diagnostics/Instrumentation/LayoutDiagnosticMetrics.cs
• src/Core/src/Diagnostics/Instrumentation/LayoutMeasureInstrumentation.cs

---

🧪 UI Tests

Full UI test matrix will run (no specific categories detected from PR changes).

---

🔍 Regression Cross-Reference

🔍 Regression Cross-Reference

🟢 No regression risks detected. No labeled bug-fix PRs in the last 6 months touched the modified files.

---

🔍 Pre-Flight — Context & Validation

Pre-Flight — PR #35475

Issue (#35473)

Title: MAUI 10 layout diagnostics no-consumer path is not zero-allocation

Symptom: When RuntimeFeature.IsMeterSupported == true (default in non-AOT builds), every IView.Measure / IView.Arrange call allocates ~376–408 B, even when no ActivityListener or MeterListener is consuming MAUI diagnostics. Comes from Activity allocation, TagList construction, struct-to-interface boxing on the IDiagnosticInstrumentation path, and a TimeSpan? boxing path.

Expected: When no consumer is attached, the layout-diagnostics path should be ~0 B/op.

PR (#35475) — Current Fix Approach (Approach A)

Files changed: 8 (+541 / −49). Functional changes in 5 files; +2 test files.

Key ideas:

1. Add HasActivityListeners to IDiagnosticsManager — a simple proxy for ActivitySource.HasListeners().
2. Gate StartLayoutMeasure/Arrange on actual consumers — before constructing any instrumentation, resolve diagnostics + LayoutDiagnosticMetrics and early-return null unless HasActivityListeners or metrics.IsMeasureEnabled/IsArrangeEnabled is true.
3. Decouple from IDiagnosticInstrumentation — the layout instrumentation structs now implement plain IDisposable and inline activity start/stop + metric recording, avoiding the struct→interface boxing that the generic StopDiagnostics(...) path caused.
4. Replace Activity.Duration (TimeSpan?) with Stopwatch.GetTimestamp() int nanoseconds — added LayoutDiagnosticMetrics.GetElapsedNanoseconds(long) (clamps to int.MaxValue, returns 0 for non-positive elapsed).
5. Add IsMeasure/ArrangeEnabled / IsMeasure/ArrangeDurationEnabled on LayoutDiagnosticMetrics so the hot path can check Counter.Enabled/Histogram.Enabled (the standard System.Diagnostics.Metrics zero-allocation gate).
6. RecordMeasure/Arrange(int duration, bool recordDuration, in TagList) — re-checks Counter.Enabled / Histogram.Enabled so disabled instruments stay branch-free.

Benchmark (per PR description):

• MeasureAndArrangeViewNoListener: 107 ns / 376 B → 16 ns / 0 B
• MeasureAndArrangeTreeNoListener: 156 ns / 392 B → 28 ns / 0 B

Tests added:

• LayoutDiagnosticsTests.MeasureAndArrangeDoNotAllocateWithoutListeners — asserts GC.GetAllocatedBytesForCurrentThread() diff = 0 over 1024 iters.
• DurationMetricsRecordWithoutActivityListeners(theory) — meter-only listener still receives nanosecond measurements.
• ElapsedNanosecondsClampsToIntMaxValue / ElapsedNanosecondsReturnsZeroForNonPositiveElapsedTime — guards on the new clamp helper.

Call sites

Only two:

• src/Controls/src/Core/VisualElement/VisualElement.cs:1999 — IView.Arrange
• src/Controls/src/Core/VisualElement/VisualElement.cs:2054 — IView.Measure

Pattern: using var _ = DiagnosticInstrumentation.StartLayoutMeasure(this); — relies on nullable-struct + using pattern (no boxing when null).

What "alternative approaches" could explore

1. Static-source / static-instrument gating — Lift ActivitySource and LayoutDiagnosticMetrics instrument refs to statics so StartLayoutMeasure can do if (!s_source.HasListeners() & !s_counter.Enabled & !s_hist.Enabled) return null; with zero DI lookup per call.
2. Per-handler cached IDiagnosticsManager / LayoutDiagnosticMetrics references — cache once on first call (or on handler attach) to avoid per-call Services.GetService<>() + dictionary lookup.
3. Volatile "any consumer" hint refreshed lazily — cache the HasListeners || IsEnabled result as a bool invalidated on Activity/Meter listener registration callbacks, so the hot path is one volatile read.
4. Move the gate from Start* callsite up into VisualElement itself (e.g. if (DiagnosticInstrumentation.AnyLayoutListener) { using var _ = … }) — minimizes the chance of paying any method-call cost on the no-consumer path.

Gate (provided)

✅ PASSED — tests fail without PR fix, pass with PR fix. Will NOT re-run.

Target platform

ios (per task input). Layout diagnostics live in Core; ios-specific behaviour isn't relevant — these are pure managed code paths shared across TFMs.

---

🔧 Fix — Analysis & Comparison

Try-Fix Aggregate — PR #35475

Summary

#	Candidate	Approach	Tests	Verdict
1	B — static ActivitySource + static layout instruments	Hoist diagnostics primitives to static readonly fields; gate hot path on `HasListeners()	Counter.Enabled	Histogram.Enableddirectly — no DI, noIServiceProvider`, no dictionary lookup

Approaches considered (from expert review) and why we stopped at one

The maui-expert-reviewer agent (Opus, 1M-ctx) analysed three genuinely different angles:

• B — Static instruments: hoist ActivitySource/Meter/Counter/Histogram to static readonly fields. Hot path is ~5–8 ns / 0 B. Smaller public-API surface than PR A (no IDiagnosticsManager.HasActivityListeners needed). One real trade-off: merges per-MauiApp sources, but the name Microsoft.Maui is a global identifier so consolidation is arguably correct.
• C — Handler-cached (IDiagnosticsManager, LayoutDiagnosticMetrics): caches the pair on the handler via interface extension or ConditionalWeakTable. Faster than PR A but slower than B. Requires either an IElementHandler API change (sticky) or ConditionalWeakTable overhead that erodes the win. Not pursued — strictly dominated by B for this workload.
• D — Process-wide static volatile bool AnyLayoutConsumer: theoretically fastest (single volatile load at the call site). Fatally flawed for activities: ActivitySource provides no "listener added" callback, so a dotnet-trace --providers Microsoft.Maui-only consumer would silently see no spans. Not pursued — would regress the user-facing diagnostics experience.

Per the task's stop criterion ("A candidate passes ALL tests and is demonstrably better than the PR's fix"), implementing Candidate B and confirming it passes is sufficient. C would be a strictly worse-or-equal alternative on this workload; D would be a regression.

Candidate B result

• Build: ✅ Core.UnitTests (5 s on rebuild), Controls.Core.UnitTests (10 s) — clean, 0 warnings, 0 errors.
• LayoutDiagnosticsTests (5 tests, including the zero-allocation regression guard): 5/5 passed.
• Controls.Core.UnitTests filter Diagnostic|Layout&Measure (11 tests): 11/11 passed.

Concrete improvements vs PR #35475 (Approach A):

1. No per-call DI lookup. PR A still does view.Handler?.MauiContext?.Services?.GetService<IDiagnosticsManager>() plus a dictionary GetMetrics<T>() lookup on the no-consumer path. Candidate B's no-consumer path is three static field reads (HasListeners(), Counter.Enabled, Histogram.Enabled).
2. No public-API addition. PR A adds bool HasActivityListeners to IDiagnosticsManager. Candidate B needs no such addition.
3. AOT/trim friendlier. PR A's hot path crosses IServiceProvider.GetService<>; B's does not.
4. Aligns with BCL design. Instrument.Enabled is the canonical zero-allocation gate exposed by System.Diagnostics.Metrics. B uses it directly; A duplicates the gating one layer higher.

Files

• try-fix-1/content.md — Candidate B narrative.
• try-fix-1/candidate-B.diff — full diff vs the PR's branch.

Open follow-up (not blocking)

If Candidate B is adopted, the now-unused IDiagnosticsManager.HasActivityListeners member added by PR #35475 should be removed for a smaller internal surface. That edit is left out of the candidate diff so the comparison stays focused on the gating-strategy change.

---

📋 Report — Final Recommendation

Comparative Report — PR #35475

Candidates evaluated

#	Candidate	Verdict	Regression tests	No-consumer hot path	Net behavioural change
1	pr — PR #35475 as submitted	LGTM (expert; confidence 8/10; no ❌ findings)	✅ Pass — LayoutDiagnosticsTests 5/5; Controls.Core.UnitTests regression filter 11/11 (per try-fix-1 baseline)	~16 ns / 0 B (PR benchmark)	Gates on per-MauiApp IDiagnosticsManager (DI-resolved); adds IDiagnosticsManager.HasActivityListeners to the internal interface; replaces Activity.Duration TimeSpan? boxing with Stopwatch.GetTimestamp() + GetElapsedNanoseconds clamp helper
2	pr-plus-reviewer — pr + expert reviewer feedback	identical to pr	✅ (same as pr)	same as pr	Empty diff. Expert produced 0 ❌ Errors, 1 ⚠️ that turned out to be a false positive (Appium change is from the orchestrator's pipeline branch, not from this PR — filtered from inline findings), and 6 💡 Suggestions that are non-blocking (hoist ns scale factor, doc on HasActivityListeners, cache IDiagnosticsManager on MauiContext as follow-up, comment on counter/histogram race, cache TagList in dual-listener path, strengthen warmup against tiered-JIT in the strict-zero alloc test). None were promoted to code edits because they are either follow-up scoped or stylistic.
3	try-fix-1 (Candidate B) — static ActivitySource + static layout instruments	Better raw perf but invasive structural change	✅ Pass — LayoutDiagnosticsTests 5/5; Controls.Core.UnitTests `Diagnostic	Layout&Measure` filter 11/11	~5–8 ns / 0 B (three static field reads: ActivitySource.HasListeners(), Counter.Enabled, Histogram.Enabled)

All three candidates pass regression. Per task rule, no candidate is penalised on the "failed regression" axis.

Head-to-head: pr vs try-fix-1

Axis	pr	try-fix-1	Edge
No-consumer latency	16 ns	5–8 ns	try-fix-1 (~8 ns saved per measure+arrange)
Allocations	0 B	0 B	tie
Public-API surface	adds bool IDiagnosticsManager.HasActivityListeners (internal iface)	no new API	try-fix-1
AOT/trim friendliness	IServiceProvider.GetService<IDiagnosticsManager>() per call (annotated, but still a dictionary lookup)	static field reads only	try-fix-1
Per-MauiApp isolation	preserved: each MauiApp gets its own ActivitySource/Meter/instruments via DI	merged: process-wide ActivitySource("Microsoft.Maui") and Meter("Microsoft.Maui") shared across all MauiApp instances	pr
Risk surface of the change	localized: gates an existing factory; IDiagnosticsManager lifecycle untouched	larger: changes the lifetime/scoping of diagnostics primitives that other (current and future) parts of the framework may have assumed per-app	pr
Reviewability / bisectability	small diff (5 prod files in src/Core/src/Diagnostics)	medium diff (4 prod files, 332 +/− 310) plus semantic shift	pr
Empirical validation depth	reviewed by maui-expert-reviewer (Opus); benchmark numbers verified; tests cover GC-allocation, meter-only listener, clamp edges	passes the same tests but only against the LayoutDiagnostics surface — no broader integration test exercises the merged process-wide source/meter	pr
Author intent alignment	matches the PR author's chosen design (gate where the consumer lookup naturally lives)	overrides the author's deliberate per-app scoping decision	pr

Where try-fix-1 wins

• Lower no-consumer latency (~8 ns). On a typical layout pass this is sub-noise; on extreme tree depths it scales linearly so it is genuine but small.
• Smaller public interface (no HasActivityListeners added).
• Removes DI from the hot path — which is the expert reviewer's [Draft] Readme WIP #1 follow-up suggestion (💡 Suggestion 4), realised more aggressively.

Where pr wins

• Preserves per-MauiApp semantics for diagnostics primitives. try-fix-1 consolidates ActivitySource/Meter instances across all MauiApps in the process. While the names Microsoft.Maui and maui.layout.* are global identifiers and tools (dotnet-trace, OpenTelemetry, MeterListener) already match by name — making consolidation arguably correct — this is a behavioural change to a public-facing diagnostics surface that the PR deliberately did not make. Multi-MauiApp per process exists today (primarily test hosts) and the framework's contract has been "one diagnostics manager per app." Changing that is a separate design decision that warrants its own PR + design review.
• Smaller blast radius. The PR touches the gate; try-fix-1 touches the gate and the scoping of the primitives. A regression in any other consumer of IDiagnosticsManager's ActivitySource/Meter would be unrelated to the perf goal.
• Already reviewed (expert: LGTM, 0 ❌, confidence 8/10). The residual 16 ns is acknowledged as a future cache-the-IDiagnosticsManager opportunity that can be done as a follow-up without changing diagnostics scoping.
• Better alignment with the broader change-management story: ship the perf fix that respects existing contracts now; revisit scoping in a dedicated PR if/when justified.

Decision

Winner: pr.

The PR delivers the stated 100% allocation reduction (0 B vs 376–408 B/op) and a >85% latency reduction (107 ns → 16 ns / 156 ns → 28 ns) with a localised, well-tested change that the expert reviewer approves (no ❌ findings; confidence 8/10). try-fix-1 is genuinely faster on the no-consumer path (8 ns saved) and removes the DI lookup, but achieves that by changing the per-MauiApp scoping of ActivitySource("Microsoft.Maui") and Meter("Microsoft.Maui") to process-wide statics — a behavioural shift the PR author intentionally avoided. The expert reviewer's "cache IDiagnosticsManager on MauiContext" follow-up captures the perf opportunity in try-fix-1 without the scoping change, and can be done in a subsequent PR. pr-plus-reviewer is identical to pr (no actionable high-severity edits surfaced).

Recommended follow-ups (non-blocking, captured in inline findings)

1. Cache IDiagnosticsManager on MauiContext or the handler (removes per-view GetService<T> lookup; closes the gap with try-fix-1 without re-scoping the primitives).
2. Hoist 1_000_000_000.0 / Stopwatch.Frequency to static readonly.
3. Add XML doc on IDiagnosticsManager.HasActivityListeners clarifying it's a hot-path gate.
4. Harden the strict-zero allocation test against tiered-JIT rejit (raise warmup, or measure on the second pass).
5. Consider removing the new IDiagnosticsManager.HasActivityListeners member only if (1) is implemented and the gate moves to a cached site that doesn't need it.

Regression cross-reference

No regression risks were detected by the orchestrator (regression-check/content.md): no labeled bug-fix PRs in the last 6 months touched the modified files.

---