mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-26 21:36:06 -04:00
3d01aaea8c
137/137 banked, 0 failed via jtbl_family_bank. R22 clean-fleet 140 passed / 0 failed of 140; report fail-closed green (dedup 1886/0, C1 coverage 239604/239604, 0 NON_MATCHING). MEASURED: fn-count 318,447 -> 318,585 (+138); instr-weighted 83.9 -> 84.0% (+12,558 ins); distinct-code 73.2 -> 73.4% (+131 unique fns — byte-VARIANT members, so unlike func_801330E0's byte-identical family this one moves the distinct number too). Closes the function REFUSED since SESSION-21 — correctly refused, since conforming its 660 declarations without first casting its 138 zero-arg call sites would have broken 138 binaries. Also logged (T21): the sweep-throughput measurement. Drew was right that parallelism was proven and adopted (Makefile JOBS=16; sweep_parallel.py -j12 built SESSION-20 after measuring an 8-16x loss), but NEITHER sweep tool calls it — the adapter is reachable only via a manual --stage-only two-step, so three sweeps today ran serially for no reason. The -j theory was wrong and measurement said so: make is ~5s of the 16s per sibling (the loop runs up to FOUR builds per sibling), so -j16 is a 12% win, kept but minor. The real 8-16x lever is blocked on revert() restoring the SHARED config/overlays.mk from git — designed, not built. An attempt to wire family_sweep's parallel default broke it twice and was reverted rather than committed.