Skip to content

defk-o08.2: compiler time measured warm in a fresh process; the chain measured again against its budget - #68

Merged
DanielLuning merged 1 commit into
mainfrom
defk-o08.2/compile-time
Oct 20, 2026
Merged

DanielLuning merged 1 commit into
mainfrom
defk-o08.2/compile-time

Conversation

@DanielLuning

Copy link
Copy Markdown
Owner

What changed

Compiler time gets a permanent, reliable harness, and the symbolic-bounds chain is measured again against its +15% ceiling (ADR-0007).

  • The harness: DEFK_COMPILE_TIME=<file> (read in Defk.__before_compile__, timed_compile/2). Every module compiles once for its result and once more in a fresh process; that second compile is measured and its microseconds and reductions are appended to the file. Without the variable, nothing changes, as with DEFK_DUMP_C.
  • dev/compile_time.exs: compares interleaved rounds of two checkouts on the modules both have, by time or with --reductions, with and without SatEx.Kernels.
  • Docs:
    • docs/agents/runs.md: the harness replaces the temporary-patch method.
    • docs/performance.md: a new entry 6.38.
    • ADR-0007's cost note: the new numbers.

Results

Why the old method was wrong:

  • It timed the first compile. Under mix dump_c, lib and test/support compile in parallel, so the first kernel module waited about 1 s for the compiler's own modules: of a 2.5 s round, about 1.0 s was that wait.
  • Timing a second compile in the same process was no better: SatEx.Kernels took either about 240 or about 510 ms on the same code.
  • With the fresh process, five compiles of SatEx.Kernels agree to ±2% in time and ±0.05% in reductions.

Measured again (99 shared modules, two interleaved rounds each, medians):

From → to Reductions Time
before step 1 (23e27970) → after step 4 (a371dcab): the chain +20.8% +13.4%
after step 4 → main (b90ed0ff): the x3a and rt2 refactors +7.3% +13.5%
before step 1 → main +29.5% +28.8%

So the compiler is about twice as far past its state before step 1 as the ceiling allows. The copy-analysis cut (defk-o08.3, the next PR) takes 9% of this back. Provisional: the laptop was on battery, with no quiet-machine check.

How it was checked

  • mix ci on the laptop (macOS) passed: 2300 tests, Credo found no issues, Dialyzer reported 0 errors.

  • The baseline and middle checkouts ran with the same harness as throwaway patches. The baseline also had the DEFK_NO_CC tooling commit (cbfb5725) applied, so that no round ran cc.

  • Touches a promised surface? No: DEFK_COMPILE_TIME is a dev knob like DEFK_DUMP_C, not documented for users. No CHANGELOG.md entry.

  • Touches test/stability/? No.

… measured again against its budget

DEFK_COMPILE_TIME=<file> makes every module compile once more in a fresh
process and log its microseconds and reductions; dev/compile_time.exs
compares interleaved rounds of two checkouts. The old method timed a
first compile, which under mix dump_c waited ~1 s for the compiler's own
modules, and a second compile in the same process varied twofold. Measured
again: the symbolic-bounds chain +13.4% time / +20.8% reductions, the
refactors after it +13.5% / +7.3%, together ~29% past the compiler before
step 1 (docs/performance.md 6.38, ADR-0007's cost note).
DanielLuning pushed a commit that referenced this pull request Oct 20, 2026
@DanielLuning
DanielLuning merged commit 2a39ee7 into main Oct 20, 2026
2 checks passed
@DanielLuning
DanielLuning deleted the defk-o08.2/compile-time branch October 20, 2026 10:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant