Repository navigation
Conversation
Why: the desktop's Memory and Tasks pages must update when another process changes a task, memory or fact. The question was how a reader in one process learns that another committed to the shared WAL-mode store, and at what cost during a sync. Results (Linux, Node 24.19.0, SQLite 3.53.3, synthetic writers): - PRAGMA data_version costs 1.3 us per check; a 250 ms poll saw every commit, p95 240 ms, 89 ms CPU per minute during a sync. - A file event on the -wal file alone found the newest commit only at the next write (4 commits seen only by a 5 s safety poll), and cost 862 ms CPU per minute with 24,375 wakeups in 20 s during a sync. Feeds cli-core docs/dev/plans/2026-11-01-events.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
WireCat Desktop's Memory page (and the planned Tasks page) must update live when an agent or another CLI changes a task, memory or fact in the shared store. This measures how a reader in one process learns that another process committed to the WAL-mode SQLite file, and what it costs while a sync writes heavily. It feeds the events design in cli-core (
docs/dev/plans/2026-11-01-events.md, branchdocs/events-design).Headline
PRAGMA data_version: 1.3 µs per check. A 250 ms poll saw every commit (p95 240 ms) at 89 ms CPU per minute during a sync.-walfile alone found the newest commit only at the next write (4 commits found only by a 5 s safety poll), and during a sync it cost 862 ms CPU per minute with 24,375 wakeups in 20 s.Decision: poll
data_versionevery 250 ms, no file watching, no daemon.Not measured: macOS, Windows, a real store, many readers at once. Synthetic data only.
🤖 Generated with Claude Code