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

	Commit message (Collapse)	Author	Age	Files	Lines
*	Say what snapshots cost the owner, and what reusing their nodes gave (107)	eunhhu	2026-09-30	1	-2/+3
\| \| \| \| \| \| \| \| \|	Most of it was the allocator: leaves past glibc's thread cache, freed by whichever thread let the last snapshot go. jemalloc was 11-14% faster at more memory; reusing the nodes in Pure gave a median +9.4% over six pairs, 4-8% less CPU a transaction in all six, and 1.97x the state bytes resident where it was 2.18x. TPC-C in RAM is now 4.0x a tuned SQLite at W=1 and 3.5x at W=4; finding items is the owner's largest part now.
*	Find pure-serve's owner by its thread, and sort its samples as 106 does	eunhhu	2026-09-30	1	-45/+74
\|
*	Say what TPC-C costs when SQLite commits in groups too, and with four ↵	eunhhu	2026-09-30	19	-0/+372
	warehouses (106) SQLite tuned first, by the criteria committed before (and, beyond them, checkpoints each 40 MB of WAL, in its favour). On the SD card Pure stays 4.2-10.8x ahead at equal terminals, SQLite writing 8-18x the bytes a transaction; in RAM 3.2-3.5x. All tables equal at W=1 and W=4, and every run consistent. In RAM the one owner is the limit (0.94 of a core at W=4, no gain from 16 to 64 terminals), a third of its busy time copying nodes the snapshots share; checkpoints and memory are within their criteria.