Memory optimizations: a third option
117 audited commits, measured, ported.
A weekend proof-of-concept: the memory savings are reproducible from a small, reviewable subset of the delivered branches.
Two options are on the table, both priced for the whole branch set
The memory-optimization work was delivered as component branches based on prplOS 4.2.0: 1,037 commits across 95 repositories, a total that counts everything on the branches, from memory work to CI configuration and packaging churn. Two integration paths have been proposed:
Option A: standard integration
Take everything through the normal review process. Sound in principle, but at 1,037 commits the review effort and timeline are prohibitive; in practice it defers the memory savings indefinitely.
Option B: expedited integration
Adopt the branches wholesale, with exceptions to the usual way of working. Fast, but it suspends the review practices that keep the codebase maintainable, and everything in the branches rides along unexamined.
Both options share one premise: capturing the memory savings requires integrating all 1,037 commits. That premise is testable, so we tested it.
A weekend proof-of-concept: audit, port, measure
- Audit every commit. All 1,037 commits were classified twice, by two independent LLM review passes; every disagreement was adjudicated by a human against the full diff. Verdict: 117 component commits (90 memory optimizations + 27 build/API dependencies) plus 9 prplOS-side commits carry the memory work. The other 920 split into 502 commits of unrelated feature work, 88 of them fix-type commits for those features, and 418 of pure CI and packaging churn: version bumps, changelogs, and pipeline configuration.
- Port and build only the subset. The audited subset was applied and built on both bases: prplOS 4.2.0, where the branches originated, and current latest-24.10. The whole port-build-measure campaign ran in ~21 hours wall-clock, over one weekend.
- Measure like-for-like. Six images (vanilla, full branch, and subset, on each base) in an identical QEMU/KVM VM: 512 MiB RAM, three boots per image, 180 s settle, medians with spreads, plus the same functional test suite on every image.
The audit also attached defect flags to 89 commits (test removals or disables, mixed scope, proprietary imports, suspected bugs); 75 of those sit in the dropped 920, flags the wholesale path would import as-is.
11% of the commits deliver the full branch’s savings
Memory improvement vs vanilla prplOS 4.2.0, medians over three boots (userspace PSS freed / MemAvailable gained). The subset’s small overshoot (+392 KiB PSS) is within per-boot spreads and is not claimed as a win on its own.
test parity Every image matches its own vanilla baseline’s functional test results; no regressions at any of the six points.
portable The same subset builds on current latest-24.10 and holds test parity there too.
Option C: integrate the audited subset, normally
Land the ~126 audited commits as ordinary merge requests through the standard MR chain: no process exceptions, no bulk import, no waiting years.
Why it works
- Review surface shrinks 1,037 → ~126 commits, a size the normal process handles.
- The measured savings are preserved (104% on 4.2.0, test parity everywhere).
- Every commit arrives with an audit rationale and a published measurement trail.
Honest caveat: this is a proof of concept
The 117-commit subset was produced in a weekend by LLM audit and porting with human adjudication. It is not the final list; the definitive set is decided during normal human review and may grow or shrink there. The PoC proves feasibility and size: the memory work fits a reviewable subset.
Deliberately out of scope: the wider framework upstep and any breaking-changes discussion proceed separately, on their own merits. This proposal only covers the memory-optimization content.
Endorse the third option
- Endorse the direction: integrate the audited memory-optimization subset through the standard MR chain, with normal human review deciding the final commit set.
- Treat the PoC as sizing evidence: a weekend of LLM-assisted work bounded the problem at ~126 commits; the memory savings do not require a multi-year program or a process bypass.
- Keep the tracks separate: unrelated features, CI, packaging, and the framework upstep are discussed on their own merits, not as passengers of the memory work.
Verify everything yourself. The full measurement report,
procedure, provenance, and the per-commit audit (all 1,037 verdicts with rationales and diffs) are published at
prplware-mem-opt-audit.pages.dev
The savings come from 11% of the branch. Review the 11%.