Repository navigation
perf: pickup-no-flush - #857
Conversation
pickUp flushed every closed document's pending track (pack, write, spin on the checkpoint's writer) before reading a kept file. It now reads a waiting copy from memory and leaves the write to the checkpoint's thread; only quitting flushes. Agent-Team: linux Worker: claude Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
PM note: how this PR will be handledWhat it is for: perf: pickup-no-flush Rules that apply: none special. Things to watch (checked by rule):
What happens next:
A living status comment below is kept current. Nothing here is a merge decision. |
Where this PR standsStage: Done: approved What the PM needs before approving (ticks as it is met; the full CI runs only at the end, after the reviews are clean):
Reviews at the current commit (
1 earlier review are for older commits and will be redone. Latest fixes comment: https://github.com/fizzyedit/work/issues/372#issuecomment-6424652322 (1 finding answered) Updated 2026-10-26 21:29 UTC by the PM. This comment is edited in place. |
A track the checkpoint's thread took (takeChanged) is no longer in pending and not yet renamed into place, so a reopen read an absent or older file and lost the restored history. pickUp now waits for writing to drain when its file is not in pending: rare, so the common reopen stays off the writer. Agent-Team: linux Worker: claude Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Part of fizzyedit/work#388
Goal
Reopening a document must never hitch:
Tracks.pickUp(run fromtickon the UI thread) no longer packs or writes on the frame, and still restores the history in every case.What changed and why
pickUpreads the newest waitingKeptFilefor the document's file straight frompending(version 1 bytes, whichtrack_file.readaccepts) instead of callingflushPending.flushPendingremains only for quitting. Review F1: a track the checkpoint's thread had already taken (takeChanged) is in neitherpendingnor on disk until its rename, so a reopen then lost or truncated the history. When the file is not inpending,pickUpnow waits forwritingto drain before the disk read: rare, so the common reopen stays off the writer.How it was verified
Test "reopening a document reads its closed track from memory and writes nothing" fails without the change (
expected 1, found 0). New test "reopening a document while the checkpoint's thread writes its track keeps the history" (takeChanged, reopen before the thread's rename) fails without the wait (expected 1, found 0) and passes with it. Both run intest-integration(94/94 steps, 427/427 tests);zb build test181/181; check-fmt clean. Reopen frame, 12.35 MB pending track, ReleaseFast, Ryzen 7 8745HS, Linux: median 32.8 ms on main, 5.3 ms here (the common path is unchanged by the wait; it only runs when the checkpoint thread holds the track). No window launched.Not done / follow-ups
The remaining ~5 ms is
track_file.readof a 12 MB track on the frame; moving that read off the frame is a separate step. A reopen during an in-flight checkpoint write blocks the frame for that write.Changes (31 files, +3140/-3615)
Gates: 6 of 6 passed
scripts/check-fmt.sh(exit 0)scripts/zb build --summary all(exit 0)scripts/zb build test --summary all(exit 0)scripts/zb build test-integration --summary all(exit 0)scripts/zb build check-web --summary all(exit 0)scripts/zb build test-sdk-version --summary all(exit 0)