Draft: audit performance across MudExtensions and identify focused follow-ups

[aarondglover]

Outcome

This library-wide audit is complete.

It did not identify another confirmed, measured performance defect that warrants an implementation PR.

Two areas remain as source-backed hypotheses only:

• MudComboBox: repeated scans/allocations around registered items and selected-value presentation.
• MudJsonTreeView: possible repeated parse/serialize work and recursive-render costs.

Neither was benchmarked strongly enough to justify an optimisation change. MudTextFieldExtended produced no compelling candidate in the initial review.

The material performance work remains focused on the existing MudSelectExtended / MudListExtended track:

• PR WIP: validate virtualized list selection state #1: virtualization/correctness fix with the major component-count and allocation reduction.
• PR WIP: add virtualized selection benchmarks #2: reproducible benchmark/profiling infrastructure and evidence.
• follow-up Select/List work can address the broader lifecycle/communication model separately.

The audit document is retained on this branch as reference. No upstream PR is proposed from PR3B itself.

---

Purpose

Document a measured, library-wide performance investigation without bundling unrelated optimisations into one mega-PR. This draft currently adds docs/performance-audit.md: initial code-backed hypotheses, benchmark requirements, regression-test scope and criteria for small follow-up PRs. No performance win is claimed in this audit PR.

Initial candidates

• MudComboBox: repeated scans/allocations over the registered Items components in chip/ItemContent presentation and selected-text updates; verify API and selection semantics before changing anything.
• MudJsonTreeView: parse/serialize and notifications in parameter setters, plus recursive rendering; profile repeated parent updates and large/nested payloads.
• MudTextFieldExtended: lightweight input/visualiser/validation hot-path review; no duplicate-list issue demonstrated and no speculative changes planned.
• Search the remaining components for analogous hot paths and record findings, including negative results.

Dependency and scope

Related fork PRs: #1 (virtualized selection fix), #2 (benchmark harness); follow-up PR 3 concerns the select's hidden list, while this is the separate PR 3B audit. Rebase onto fork dev after dependencies land to use the validated harness. PR 4 (async/paged data) is out of scope.

Each independently actionable improvement gets its own focused PR with equivalent before/after benchmark inputs, settled render checks, allocations/time/component counts as applicable, and protective regression tests. Keep the audit as a findings-and-links document, not an implementation catch-all.

This is fork-only and draft. Do not merge or submit upstream until the benchmark methodology, findings, and intended follow-up slices are reviewed.