lectio.git/mobile/mobile_test.go, branch perf/hoist-date-independent-workoffline Catholic daily readings and liturgical calendar in Go, with CLI, TUI and web clientshttps://git.labunix.xyz/lectio.git/atom?h=perf%2Fhoist-date-independent-work2026-08-24T14:35:01Zperf(readings): stack calendar layers and load the book table once per Days call2026-08-24T14:35:01ZLukasz Kasprzaklukas@labunix.xyz2026-08-24T14:35:01Zurn:sha1:b6ee8f09ad2c0bc9e83394e2427de861eb1e2a72
mobile.Days (dlectio's 7-day calendar view) called readings.Load once per
date. Load's offlineLoad re-ran caldata.Stack (parses the embedded
calendar INI, plus any user calendar layer) and bible.LoadBookTable
(parses the embedded books.ini, plus any user override) on every call,
even though neither depends on the date -- only on cfg.Selection().Form
and cfg.Use, which mobile.Days holds fixed across its whole loop.
Verified before changing anything: isolated benchmarks put Stack+
LoadBookTable at ~1.1ms/call (OF) and ~1.6ms/call (EF) -- real INI
parsing and, for a user override, file I/O -- and for the OF form that
redundant work was ~67% of a 7-day view's total time.
Load gains a Prepared value (the layer stack + book table) and a
Prepare/LoadWith pair: Prepare builds a Prepared once, LoadWith reuses
it across dates. Load itself is unchanged, still calling Prepare on
every invocation -- every existing caller keeps its current behaviour
untouched. mobile.Days now Prepares once and loops LoadWith; mobile.Day
picks up the same fix for its own two same-cfg Load calls.
Benchmarked (interleaved before/after pairs, to control for machine
thermal drift): the OF 7-day view (BenchmarkDaysWeek) drops from
~11.5ms to ~6.4ms/op (allocs 53359 -> 16347, -69%), an EF 7-day view
(BenchmarkDays7EF) from ~74ms to ~66-73ms/op (allocs 299204 -> 253815,
-15%; the EF form's per-day calendar computation dominates its total
cost far more than OF's does, so the fix's share of the win is smaller
there), and a single Day call (BenchmarkDay1) from ~4.3ms to ~2.9ms/op
(allocs 15357 -> 9192, -40%).
Output identity verified separately (not part of this diff): a 288-case
sweep of mobile.Day/mobile.Days across both forms, both UI languages,
all four corpora, a leap day, the Sacred Triduum, a Requiem day, and
windows spanning Christmas/Pentecost/Assumption/All Souls produced
byte-identical (SHA-256-equal) JSON before and after this change.
New TestLoadWithAgreesWithLoad asserts LoadWith(Prepare(cfg), cfg, opts)
equals Load(cfg, opts) for every case, so the fast path cannot silently
drift from the slow one. go test ./... and make ci (both build tags,
oracle/differential suite included) are green.
readings: PartIDs(new) stops declaring aklamacja, which the engine never emits2026-08-05T12:10:34ZLukasz Kasprzaklukas@labunix.xyz2026-08-05T12:10:34Zurn:sha1:eb4a02205f5b3b972c44b854d5becbbd0b522981
caldata.go:42 parses only first/psalm/second/gospel out of the lectionary
data, so no OF reading ever carries Part == "acclamation". PartIDs("new")
listed aklamacja anyway, so the app built a checkbox from it that filters
an ID that never appears -- a dead control, same defect class the app
previously shipped for the whole 1962 form.
ofPartOrder stays the full five-ID set: it also drives
render.LocalizeHeading's label matching, where a scraped heading can still
read "Aklamacja" even though this engine's own readings never produce
that section. PartIDs now draws from a new, narrower
ofEmittedPartOrder instead.
Rewrote TestPartLabelsMatchesWhatTheEngineEmits's OF half: it compared
PartLabels("of") to a hand-copied duplicate of ofPartOrder, asserting a
declaration against itself, which cannot fail for this class of bug. It
now sweeps Days over calendar year 2026 and asserts PartLabels("of")
matches the observed part-ID set exactly (0.5s). Confirmed red against
the pre-fix code, green after.
mobile: strengthen the PartLabels fallback test and count bounds2026-08-03T22:11:23ZLukasz Kasprzaklukas@labunix.xyz2026-08-03T22:11:23Zurn:sha1:197ce6980daa1c3773eed1548f54861d616d35e4mobile: add PartLabels so the app stops hardcoding part IDs2026-08-03T21:59:50ZLukasz Kasprzaklukas@labunix.xyz2026-08-03T21:59:50Zurn:sha1:1106568c52265ea3076b9d3f1943c052c83a2a89mobile: add Days, a text-free week projection for the calendar2026-08-03T21:59:09ZLukasz Kasprzaklukas@labunix.xyz2026-08-03T21:59:09Zurn:sha1:27ceffcb90c0716179342109163c559d492a8abc
A week through Days benchmarks at ~9-10ms/op, versus ~23ms for seven
full days through Day.
mobile: return the day's rank and its localised label2026-08-03T21:56:14ZLukasz Kasprzaklukas@labunix.xyz2026-08-03T21:56:14Zurn:sha1:13d5e99ab90ab872c8cc072a0246348f0d24fa9a