Timeline

chore(release): v0.17.0 leaf check-in: c530a8e967 user: [email protected] tags: main, trunk, v0.17.0

docs: the libfossil_noslog tag, and how the publisher engine gets smaller still check-in: 33ecaf10e6 user: [email protected] tags: main, trunk

The TinyGo section of the install guide and examples/tinygo described libfossil_nohttp but not libfossil_noslog, which only the changelog mentioned. Both now say what the tag leaves out and what changes.

The install guide gains a "Smaller still" section pointing at the html-artifact-publisher engine's build: no scheduler, a reactor export, explicit panic unwinding and a patched standard library, with the behavior the patch changes. It says plainly that these steps are the publisher's and that this repository does not build that way.

CI never compiled the code behind either tag, so a change could break a tagged embedder unnoticed until the publisher's CI ran against a release. A new build-size-tags job builds the library under both tags, vets the repository under libfossil_noslog, and runs the check-in linker's tests under it. check-in: b451efa274 user: [email protected] tags: main, trunk

Keep regexp, strings.Replacer and log/slog out of small builds check-in: f338cac5ba user: [email protected] tags: main, trunk

With the tag the diagnostics go to stderr, so the five tests that read them back from a slog handler skip. CHANGELOG notes the tag and that regexp and strings.Replacer no longer come in through the library. leaf check-in: 73812b88e0 user: [email protected] tags: main, spike/wasm-size, trunk

Spike for a smaller TinyGo engine (html-artifact-publisher). Behaviour on every platform is unchanged:

- repo: table names are checked with a byte loop, not a regexp, so a build that uses no other regexp leaves package regexp out (about 69 KB gzipped in the publisher's engine, with the engine's own two regexps). - fsltype: HTMLize escapes with a byte loop instead of a strings.Replacer (about 15 KB gzipped). - manifest: the package's diagnostics go through logDebug, logInfo and logWarn. By default they call log/slog as before. With the libfossil_noslog build tag they are written to stderr as plain lines and log/slog stays out (about 33 KB gzipped). Tests that assert on slog output need the default build. check-in: 2abfe81c2a user: [email protected] tags: main, spike/wasm-size, trunk

perf(content): memo review follow-ups: per-hit expandability, purged-baseline test, lineage order check-in: 23c3e0486e user: [email protected] tags: main, trunk

Corrupt or undecompressable content still passes the check, though a fresh read would skip that tree. check-in: 959c7e35ae user: [email protected] tags: main, perf/memo-review-nits, trunk

Each view that served a kept tree listed every rid its store could not expand, by a recursive walk seeded with all of the store's phantoms. A horizon-serving peer can hold tens of thousands of phantoms: on a copy of fossil-scm.org's store with 39.7k of them, that list cost about 100ms of every warm view (200ms against 105ms).

A hit now walks the kept tree's own chain of delta sources up to the first rid whose answer is known. Within a lineage an answer never changes, so views publish the answers they found and the memo keeps those of its latest lineage, which replaces them; each delta step is read once per lineage, for the trees actually looked up. The per-lineage scan for delta sources a store holds no row for goes with it: the walk meets a missing row itself. On fossil-scm.org the first view of a lineage to serve 1000 kept trees pays about 10ms; whole history after a full read is unchanged.

The stock-fossil shun test passed with both guards removed: shunning a check-in drops it from the held set, so its tree is never asked for. It is replaced by a purged baseline that the held set's delta manifests go on citing, with the horizon asserted placed. Stock fossil never leaves a store so (its purge refuses a baseline without its deltas, and rebuild leaves those uncrosslinked), so the test deletes the baseline's rows as such a purge would, from a store fossil wrote; a second case puts another blob at the freed rid, which only the held-name check catches.

Also documents why a lineage numbered at view start rather than at the read snapshot is safe: a view on an older snapshot may publish over a newer store, which costs the next view an extension or a full read and is never wrong. leaf check-in: 39b24649b0 user: [email protected] tags: main, perf/memo-review-nits, trunk

perf(content): keep the memo's trees for the life of the memo (HZ-6.2-10) check-in: dd58b95c70 user: [email protected] tags: main, trunk

Review of the tree memo found it could classify differently warm than cold. A kept tree was served whenever the store held its name at its rid, even when the store could no longer expand it (a delta whose source became a phantom or lost its row), where a fresh read skips the tree. Each view now lists, once, the rids its store cannot expand: a recursive walk of the delta table seeded with the phantoms and the delta sources the store holds no row for. Those sources only appear when a row is deleted, which forces a full read, so they are found once per lineage (about 20ms on fossil-scm.org) and the per-view walk costs about 0.3ms. The phantom check folds into it.

Publish dropped the trees a view read whenever the memo had gone past that view's store, though trees do not depend on the store; they are now kept either way. A view over a store read in full after the memo's is no longer taken for a stale one, so a store whose highest rid was deleted stops being read in full on every view.

The names bound that replaced the byte cap counted pieces, not names, so one publish could pass it; it now counts the names each piece adds, on the fresh-index path too, and is passed as a parameter so it is tested.

The tests compare the names a horizon's walk produces, memo against fresh, which classification alone can hide: a tree's lost nodes also stop its files counting as files. They lose trees as phantoms, as deleted nodes, behind phantom and deleted delta sources, and by a shun and rebuild in stock fossil; removing either check fails them. check-in: c50ff7c9e2 user: [email protected] tags: main, perf/463-memo-trees, trunk

HZ-6.2-10 asks that an origin read each structural artifact's F cards once per store. The memo's tree index already kept fossil-scm.org's whole tree history in about 11MiB, yet it still read trees again in two cases: past a 64MiB bound, and after any full read of the store, which dropped the index with its lineage.

Neither was needed. A tree piece is what its name's bytes say, so it is valid in every store that holds the name; the rid it was read at is checked against the view's own rid-to-name map, and a renumbered store reads it once more and moves it to its rid. The index grows with the store like the reference graph beside it, so the byte bound goes; only a names bound at the most artifacts a classified store can hold remains, which one store cannot reach.

On the fossil-scm.org clone a horizon 2000 back after a full read now takes 1.0-1.8s instead of 4.3-6.2s, and the whole history after a full read reads no tree (1.3-1.5s, from 14-17s). Cold runs and peak heap are unchanged. HZ-6.2-10 is now covered; the trees still enter the graph when a walk first reaches them, as the reverted eager read cost 4-5x cold. leaf check-in: bfce209a24 user: [email protected] tags: main, perf/463-memo-trees, trunk

The corpus test timed horizons cold and warm, but not the case HZ-6.2-10 left open: a full read of the store (an arrival a held artifact cited) dropped every tree the memo had read. It now times a horizon again after one, and a second test walks the whole history to report what keeping every tree costs in heap and time. check-in: e690ff7ad2 user: [email protected] tags: main, perf/463-memo-trees, trunk

fix(sync): a horizon store refuses a pull it does not hold and mints no seed check-in: 301c8e2337 user: [email protected] tags: main, trunk

A refusal keeps only gimmes, errors, messages and the session-level pragmas, so a pull-side card type added later is dropped until judged safe. The refused-pull case now asks for every pull-side card kind and asserts the reply holds only allowlisted types. check-in: fb36eb5653 user: [email protected] tags: feat/horizon-peer-serving, main, trunk