Skip to content

Fix: Read browser memory in place in the tab strip, app window and browser readers - #185

Merged
b-re-w merged 1 commit into
developfrom
feat/word-reads
Nov 9, 2026
Merged

b-re-w merged 1 commit into
developfrom
feat/word-reads

Conversation

@b-re-w

@b-re-w b-re-w commented Nov 9, 2026

Copy link
Copy Markdown
Member

Follow-up to #183. After it, release address-typing (.scratch\typing-after-release) gave Rivet work per key median/p90:

Browser median ms p90 ms
Chrome 157 28.7 40.3
Whale 5.39 12.1 15.3
Edge 157 14.5 22.6
Brave 157 11.9 16.4
Samsung 30 9.6 16.5

Most of what is left is the top bar's own paint (draw median 7 to 19 ms). Its view reads the open tabs through the tab strip reader, and that reader made one ReadProcessMemory call per word, as second_view's did. This applies the same in-place read (after memory::readable) to tab_strip::read, app_window::safe_word and browser::chromium::read_word. It also traces top bar: update took N us: view .. paint .. over 2 ms, so the next measurement splits the view from the paint.

Covered by nfr2_browser_words_are_read_in_place_once_readable (#183); the after numbers come from the same scene.

🤖 Generated with Claude Code

…owser readers

The tab strip's, the app window's and the browser access layer's readers made a system call for
every word of browser memory, as the second view's did. Memory already known readable is now read
in place, with ReadProcessMemory kept for the rest. The top bar's own repaint traces its steps
when it takes 2 ms or more.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@b-re-w
b-re-w merged commit 89082e9 into develop Nov 9, 2026
3 checks passed
@b-re-w
b-re-w deleted the feat/word-reads branch November 9, 2026 19:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant