pure - Verified execution runtime unifying state, persistence, and replication.

	Commit message (Collapse)	Author	Age	Files	Lines
*	Measure what moving saves off the owner would buy (084)	eunhhu	2026-09-27	1	-2/+30
\| \| \| \| \| \| \| \| \| \| \| \|	Nothing a thread can give: with writes saturated the device's one line of syncs is the bottleneck, so zeroing the tail or compacting on another thread only queues that device work behind the commits, and the owner's idle gap is shorter than one journal commit. Built without compaction the store is no faster; without compaction and without tail growth durable posts gain 1.4% and the p99 drops 24% (17.4 to 13.3 ms). New blocks are the tail latency, so the way to it is a store that rewrites its space in place, a ring cleaned forward instead of compacted into new files.
*	Measure whether sharding owners by key would add writes (084)	eunhhu	2026-09-27	1	-0/+47
	It would not, on this device. One file's syncs or four at once, the SD card completes the same 510-690 commits per second, the latency growing with the number of files. The scoreboard app with two owners, each with a store of its own, took 23% fewer durable posts than one owner (median 16,230 against 20,974 a second) with 2-3x the p99: syncs queue, and each carries half the events. One owner's group commit stays; cores serve reads, and writes grow by making the sync itself cheaper.