Parents and children of check-in [0ef543c27a]
|
2026-08-23
| ||
| 23:32 | merge landing-doc: correct the cost note, drop the forge name check-in: 95ea2cb6b1 user: dmestas tags: trunk | |
| 23:25 |
landing: correct the cost note, and stop naming a particular forge
The module doc claimed stores of this size read in milliseconds. They do not -- a 117MB mirror scanned for 62 seconds. The claim was carried over from a WRITE path taken once per ticket change onto a READ path taken per view, where neither the frequency nor the scale held. Removed rather than softened, with what the scan actually costs written down: still linear in store bytes, which the constant-factor fix did not change. The doc also named quarry throughout. zit provides the hooks; what is built on them is not zit's business, and naming one forge in the code reads as though it were. closed check-in: 78d56a2177 user: dmestas tags: landing-doc | |
| 22:46 | merge landing-scan: the fold stops parsing every blob check-in: 0ef543c27a user: dmestas tags: trunk | |
| 22:36 |
landing: stop parsing every blob to find the records
The fold called artifact.parse on every artifact in the store and let it fail on the content blobs, which are most of a real store's bytes -- and a parse attempt pays a whole-bytes Z checksum before rejecting one. It now applies the reject-fast pre-screen frames --structural already uses, and reuses one plaintext buffer instead of allocating per artifact. zit landing ls, release build: quarry 1.06s -> 0.15s, zit 2.19s -> 0.31s, libfossil 8.49s -> 0.91s. A forum-shaped store is unchanged, because there is nothing to reject there; it was never the slow case. The screen only rejects. Every accept still takes the full parse, so nothing the fold would refuse can be admitted by being shaped like a card. closed check-in: 8776c0e5bb user: dmestas tags: landing-scan | |
| 21:50 | merge landing-show: the check-ins being proposed, and the thread check-in: 54badbba6a user: dmestas tags: trunk | |