Re: [PATCH 00/23] kbuild: significantly speed up kernel builds

From: Daniel Campos Ramos

Date: Tue Oct 20 2026 - 14:38:01 EST


Hi Lorenzo, Linus,

I maintain Sparky Stereo OS and have preliminary measurements of preparing reduced compiler inputs ahead of consumption.
Our Lean Code pipeline retains the complete authored source and generates a representation with removable comments eliminated, preserving required directives and source locations.
The aim is fewer bytes for repeated consumers to read and scan.

On an AMD A10-9600P laptop with 12 GB RAM and SATA SSD storage, our 17 October header experiment changed 6,290 files out of 10,352 examined.
The changed subset went from 61,154,706 to 44,167,571 bytes: 16,987,135 fewer bytes (27.8%).
Preparing it with two workers took 258.94 seconds.
These are file-size figures, not measured disk reads.

Using the prepared headers, the elapsed-time medians were:

pairs authored lean
Qt umbrella, syntax only 20 9,284.25 ms 9,259.50 ms
Qt umbrella, -O2 -g 20 10,970.60 ms 11,046.45 ms
Qt umbrella, preprocessing 20 882.45 ms 890.25 ms
acpi_call module, -j1 10 4,672.95 ms 4,677.45 ms
v4l2loopback module, -j1 10 6,572.40 ms 6,541.05 ms

All builds exited successfully, but these measurements do not establish a compilation speedup.
The experiment used engine 0.1.2, always ran authored before lean within each pair, and used different header paths; it does not establish binary equivalence either.
We have not measured full-kernel builds.
Any benefit from reuse must also repay the preparation and verification cost.

Separately, with engine 0.1.3 on the same laptop, eight paired application-start rounds with variant order reversed each round gave these median paired window-time changes:

cold warm cold pairs faster
plasmashell -159.9 ms +43.8 ms 7/8
Dolphin -66.7 ms -6.9 ms 5/8
Discover -70.6 ms -1.4 ms 6/8
System Settings -38.1 ms -41.9 ms 4/8

Those used 95 selected runtime text files in a nested headless environment.
CPU temperatures ranged from 63 to 91 degrees C, so these are preliminary observations, not evidence of a general speedup or a kernel-build result.

The policy and implementation are public:
Policy: https://github.com/danielcamposramos/driver_stereodisplay/blob/main/sparky-os/LEAN-CODE-POLICY.md
Implementation: https://github.com/danielcamposramos/driver_stereodisplay/tree/main/sparky-os/lean

Would a controlled kernel-build comparison, including preparation cost and repeated-use break-even, be useful to this discussion?
I can provide the raw records behind these preliminary numbers.

I develop this with Claude and Codex as AI partners and take responsibility for this report.

Daniel Campos Ramos