docs/slate-issues/benchmark-candidate-map.md
This file is the benchmark handoff layer.
It exists so a maintainer can choose a performance issue and start a reproducible workload lane without rereading the full GitHub thread.
Live-state note:
682 open issues628 open issues54/54 closedslateready-nowpackages/slate/test/perf/set-nodes-bench.jsThis issue is already framed as a benchmark-driven engine problem. The workload class, success criteria, and active implementation seam are all explicit.
set_node batchesTransforms.applyBatch(...) and manual Editor.withBatch(...)Do not turn this into one giant benchmark lane. Keep it split by operation family and mixed-batch shape.
slateready-with-minor-setupThe workload now has a stable harness lane in
.tmp/slate-v2/scripts/benchmarks/core/current/clipboard-large-payload.mjs.
The issue-size gate is:
SLATE_CLIPBOARD_BENCH_HUGE_CUT_BLOCKS=50000 SLATE_CLIPBOARD_BENCH_ISSUE_TARGETS=1 bun ./scripts/benchmarks/slate/5945-large-plaintext-paste.mjs
The current proof supports Improves #5992, not Fixes #5992: exact
whole-child range delete lowers to one replace_children operation and meets
the accepted warm interaction benchmark target, and browser stress covers a
5,000-block huge-document cut row. Exact closure still needs maintainer
acceptance that the benchmark plus browser stress matches the original repro.
The harness exists, the warm interaction target is green, and a browser huge-document cut row exists. Exact closure now depends on whether maintainers accept the cold snapshot allocation row as startup/editor-preparation cost and the 5,000-block browser stress row as sufficient user-path coverage.
Build one narrow benchmark lane first:
slateready-nowThe issue already has a reproducible workload and contributor profiling that points at the expensive seams.
Do not benchmark “paste is slow” as one opaque blob. Break out the normalization-heavy path and the editor-validation path if the harness can expose both.
slate-reactready-nowThe issue already has a concrete workload, a performance claim with before/after numbers, and a narrow renderer seam.
decorate churn versus local per-node decoration renderingThis is not a generic “decorations are slow” complaint. It is specifically about the global invalidation model in slate-react.
slate-reactready-with-minor-setupThe issue has a concrete workload and the thread already frames the core complaint as rerender breadth, not vague slowness.
The harness still needs one lane that isolates leaf breadth inside a single block instead of whole-editor rerender pressure.
Add one narrow slate-react perf lane for many-leaf blocks and a single edited leaf.
slate-reactready-nowThe issue already frames a concrete workload: one paragraph, lots of inline nodes, then normal typing, paste, and backspace falling off a cliff.
The harness still needs a narrow lane for one-inline-heavy paragraph instead of whole-editor rerender pressure.
Add one slate-react perf lane for a single paragraph with many inlines and edit one inline repeatedly.
The pilot already proves benchmark extraction is a separate artifact, not a footnote under TDD. Performance issues want workload capture, metrics, and harness seams, not fake red-test prose.
The 25-issue expansion did not add new benchmark-worthy issues beyond the existing large-document and batch-engine lanes. That is useful signal too. Most of the new batch was correctness, input-method, or ecosystem triage, not hidden perf work.
The 76-issue mark still says the same thing. Even the stronger runtime-design issues in the new batch, like #5697, are architecture and correctness pressure first, not benchmark-first workload reports.
The 101-issue mark still did not add a genuine new benchmark issue. That is good discipline: not every painful bug deserves a perf harness, and this batch was overwhelmingly runtime semantics, browser integration, and API shape.
The 251-issue mark still did not produce a cleaner new benchmark target than the existing large-document, selection, and batch-engine lanes. This batch was mostly DOM ownership, mobile input, plugin seam, and API-shape pressure rather than hidden perf work.
The 301-issue mark still does not surface a cleaner new benchmark target than the existing large-document, selection, and batch-engine lanes. This 50-issue tranche was mostly DOM bridge, mobile input, typing, docs/example debt, and plugin/runtime seam pressure rather than fresh hidden perf work.
The 351-issue mark still does not produce a cleaner benchmark target than the existing large-document, selection, and batch-engine lanes. This tranche was dominated by runtime-boundary, clipboard-strategy, mobile input, and docs/example pressure rather than fresh performance reports.
The 401-issue mark finally adds one clean new benchmark lane: dynamic decorations in slate-react from #4483. Most of the rest of that tranche still leaned runtime-boundary, mobile input, Shadow DOM, and docs/example pressure rather than hidden perf work.
The 451-issue mark adds one more real renderer-performance lane: rerender breadth in #4210, with #4141 as the depth-sensitive variant of the same problem. The rest of this tranche is still dominated by selection, composition, plugin-surface, and example/process noise.
The 501-issue mark adds one older but still legitimate large-document clipboard lane from #4056. Most of this tranche still reinforced IME, focus, iframe, readonly, and docs/process pressure rather than surfacing a pile of new perf work.
The 551-issue mark adds one real history-memory benchmark lane from #3752. Most of this tranche still leaned history semantics, cross-window runtime ownership, IME, and docs/example pressure rather than a flood of fresh perf reports.
The 601-issue mark adds one older but still useful slate-react renderer lane from #3656: leaf rerender breadth inside a single block. Most of the rest of this tranche still reinforced focus ownership, Android/input debt, history semantics, and structural delete failures rather than surfacing a pile of new perf work.
cross-packageready-with-minor-setupThe workload is concrete and user-visible, and the thread keeps pointing back to large-document ingest cost rather than one weird payload.
The package benchmark lane now covers populated-editor copy and middle paste at 10,000-block scale. Exact browser closure still needs the historical full-book/user-path repro.
Add the browser/user-path reproduction before upgrading the claim beyond Improves.
slate-historyready-nowThe issue has a concrete reproduction path, a measurable memory symptom, and a strong hint about where retained references are coming from.
This is a memory-retention lane, not a latency lane. Treat it like a leak benchmark, not a typing benchmark.
slate-dom and slate-reactready-with-minor-setupThe workload is tight: one browser, one document shape, one user-visible lag path.
This still needs a stable Safari harness, not just a screen recording.
Build one browser-scoped lane first instead of pretending this should be cross-browser by default.
slate-reactready-nowThis is a clean subscription-granularity question: how much work does useSlate do when only selection changes?
useSlateThis is not about micro-optimizing hooks in the abstract. It is about whether slate-react subscriptions are too broad.
slate-reactready-nowThe issue is already a clean renderer invalidation complaint with a public repro path and an obvious measurement target.
This is the same family as the later nested-block rerender issues, so it should become one reusable renderer benchmark lane, not five nearly identical ones.
slate-reactready-with-minor-setupThe pain is concrete, but the benchmark should be framed as a depth-sensitive variant of the broader rerender-breadth lane instead of its own silo.
It still needs a stable public harness instead of screenshots from React devtools alone.
Add one depth-aware variant to the rerender benchmark lane instead of inventing a separate perf harness.
The 651-issue mark adds one real older slate-react perf lane from #3430: single-paragraph many-inline editing where render breadth and typing latency collapse together. The rest of this tranche mostly reinforced focus ownership, placeholder behavior, decoration invalidation, Android input, and extension-surface pressure instead of surfacing a pile of new benchmark work.
slateready-nowThe issue already names the hot path and ties it to a reproducible large-paste workload.
This should stay narrow. The useful comparison is dirty-path tracking cost, not “paste is slow” as one opaque blob.
slate-reactready-nowThe issue directly frames a measurable runtime problem: simple native edits should not force broad rerender work.
This lane is about runtime invalidation breadth. Do not mix it with IME correctness or spellcheck behavior.
slate-reactready-with-minor-setupThe issue has an obvious workload and user pain, but it still needs a stable harness shape for windowing or deferred render comparisons.
The benchmark still needs a stable huge-document fixture and a fair comparison seam. Windowing strategies that break DOM lookup are not useful baselines.