You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TUI: each prompt keystroke re-registers keymap layers (~15 ms JS per key) #60681
Every keystroke in the TUI prompt costs ~15 ms of JS before anything is drawn. strace shows the main thread on CPU for the whole interval from reading the key to writing the screen, and a JS sampling profile puts about half of it in useKeymapSelector memos.
Cause: several prompt keymap layers compute an eager enabled boolean from per-keystroke state inside their Keymap.createLayer factory, in packages/tui/src/component/prompt/index.tsx:
the prompt.clear layer reads store.prompt.text
the ! shell-mode, backspace-exits-shell and history ↑/↓ layers read cursorVersion(), which is bumped on every content and cursor change
the stashCommands memo reads !!store.prompt.text and returns a new array, so its layer re-registers too
So each key unregisters and re-registers about 6 layers. The keymap emits state, and every useKeymapSelector memo recomputes, including one useShortcuts() memo per caller, each of which rebuilds a formatted Map of every registered command (context/keymap.tsx).
Time from a key written to the TUI's PTY to its first output byte (60 keys, fresh session, three interleaved rounds):
build
p50 ms
p90 ms
v2.2.1 release
15.9 · 14.4 · 14.7
23.8 · 18.4 · 18.8
v2.2.1 built from source
15.9 · 14.2 · 18.7
21.8 · 17.5 · 24.3
same + lazy enabled (PR)
3.8 · 3.6 · 3.9
5.8 · 4.4 · 7.1
It doesn't depend on session size. The code is unchanged in v2.2.4 and on dev.
Plugins
none (reproduced with an empty config)
OpenCode version
2.2.1 (same code in 2.2.4 and dev)
Steps to reproduce
Run opencode serve and attach the TUI to a session on a PTY you control.
Write single printable characters to the PTY ~200 ms apart (never submit).
Time each write to the TUI's next output byte: ~15 ms p50. A shell on the same PTY echoes in <1 ms.
Operating System
Ubuntu 24.04 (x86_64, 8 vCPU)
Terminal
PTY driven by a test harness; also felt over ssh in iTerm2
Thanks for the detailed report and the PR. I could reproduce this.
I ran the TUI on a PTY with an empty config, wrote 60 single characters 200 ms apart without submitting, and timed each write to the first output byte:
The absolute numbers are lower than yours (probably a faster machine), but the gap is the same. That fits the prompt keymap layers re-registering on every keystroke, and it still happens on the latest dev. The script below is the PTY harness I used. The recording shows the typing session, though a delay this small doesn't really show up on screen.
Activity
isaacturnbull commentedon Oct 30, 2026
Fix: #60682
opencodejr commentedon Oct 30, 2026
Thanks for the detailed report and the PR. I could reproduce this.
I ran the TUI on a PTY with an empty config, wrote 60 single characters 200 ms apart without submitting, and timed each write to the first output byte:
dev(bf5d12c), from sourcedev+ #60682The absolute numbers are lower than yours (probably a faster machine), but the gap is the same. That fits the prompt keymap layers re-registering on every keystroke, and it still happens on the latest
dev. The script below is the PTY harness I used. The recording shows the typing session, though a delay this small doesn't really show up on screen.Related: #60682 (your fix) and #59294 (keeping keymap command objects stable).
recording.mp4
Reproduction script (latency.py)
Run it:
python3 latency.pysimonklee commentedon Oct 31, 2026
This will be fixed soon, thanks for reporting.