geekinney/ekp
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
83352c4571
ekp/.phrase/phases/phase-kp-overhaul-20260726/issue_narrow_live_append_latency_20260729.md
Kinneyzhang 83352c4571 feat!: add source-clean live buffer layout 
Replace the physical ekp-region renderer with ekp-buffer text-property projection backed by shared semantic layout plans and stable live-edit transactions.

Optimize the C-backed resize hot path, and add deterministic performance, ERT, GUI, fuzz, release, and documentation coverage for task017 through task032.

BREAKING CHANGE: require ekp-buffer instead of ekp-region and rename module-owned ekp-region-* settings to ekp-buffer-*.
2026-07-30 01:07:25 +08:00

3.1 KiB
Raw Blame History

Issue: Narrow Live-Append Latency 2026-07-29

issue018 [ ] Unique live appends miss the frame budget at very narrow widths

  • Status: Re-profiled after task031; task030 is unblocked.
  • Summary: Stable transactions removed per-key whole-hard-line planning. The synthetic 80-pixel workload now performs zero planning on ordinary same-row edits, but structural row-crossing commits still make append p99 exceed the 16 ms frame budget.
  • Environment: Emacs 30.2 on macOS, C backend 1.6, benchmark width fixed at 80 px, gc-cons-threshold bound to most-positive-fixnum so mutator work is measured without GC pauses.
  • Repro:
    1. Load the C backend.
    2. Run tests/ekp-buffer-live-bench.el with GC excluded.
    3. Inspect the append row.
  • Expected vs Actual:
    • Expected: live append p99 remains below the 16 ms interaction budget, including narrow windows.
    • Actual: the final task031 GC-excluded runs record only 15 permitted structural plans across 291 appends. C measures median 2.177 ms and p99 51.170 ms; Elisp measures median 2.176 ms and p99 187.499 ms. Same-row cache-revisit work records zero plans (C p99 1.627 ms; Elisp p99 1.502 ms), while point motion records zero plan/cache calls (C p99 0.017 ms; Elisp p99 0.015 ms).
  • Investigation:
    • The task029 point-motion change is not the cause. Navigation is now a zero-work path and does not enter planning or projection publication.
    • The old workload produced 291 distinct hard-line strings and 291 plan calls. task031 removes that obsolete control flow: only 15 actual visual-row crossings invoke ekp-layout-plan.
    • The remaining high percentiles coincide with those allowed structural commits and must be profiled as commit latency, not average key latency.
    • Wider measurements are materially faster; the pathological result is width-sensitive rather than a general point-motion regression.
    • The previously recorded 6.399 ms task028 append p99 is not reproducible with the current checked-in benchmark and must not remain the current performance claim.
    • Both backends still miss p99 at structural boundaries, so task030 must evaluate both rather than optimize only the C wrapper.
  • Required Outcome:
    • Diagnose and reduce unique-state narrow-width append planning cost without changing KP output semantics, the core DP contract, C ABI, or source-clean display model.
    • Keep cache identity exact; do not introduce approximate/stale plan reuse, timers, skipped edits, global GC changes, or point-based invalidation.
    • Preserve the task029 invariant that point-only motion performs zero plan, cache, and text-property work.
  • Fix: Deferred to task030; the prerequisite correctness replacement is complete. Optimize only the surviving structural-commit path.
  • Verification: Future work must use a reproducible width matrix, profiler evidence, result-equivalence tests, default-GC and GC-excluded runs, and GUI input evidence.
  • User Confirmation: Not applicable until a performance change is implemented.
  • Resolved At: Unresolved.
  • Resolved By: Pending.
  • Commit: Pending.