00431a7a8a
Last iteration I wrote that build-reborn test cannot finish in a working session, from having watched it run 3h26m. That was the stronger claim and I made it without measuring the work. Timing `mesh info` on each of the 166 .xpr containers with a 25 s cap: files scanned 166 exceeding 25 s 19 Hangar, 17 Stage_*, ptc_pack Stage_S02 to completion 144 s, rc = 0 Nothing hangs. Nineteen heavy containers at roughly two minutes each is about 45-60 minutes for one pass, before the 147 fast ones. The 3h26m observed was that hour of work running at a load average of 9-14 -- inflated by the two duplicate runs I had left going, which did not merely coexist with the slowness but multiplied it. The practical conclusion is unchanged and only the wording softens: an hour-scale suite is not an iteration-scale gate, and every "green" I reported from it this session was partial. But an hour-scale gate can be run deliberately, whereas a hung one cannot be run at all, so the distinction is worth having right. File list committed as reference data so the cost is attributable without re-scanning. METHOD: a slow thing observed under contention looks like a stuck thing; measure the work before choosing between "cannot finish" and "takes an hour".
23 lines
426 B
Plaintext
23 lines
426 B
Plaintext
# .xpr files whose `mesh info` decode exceeds 25 s (debug build), of 166 scanned
|
|
# 2026-08-29. Stage_S02 measured at 144 s to completion, rc=0 -- heavy, not hung.
|
|
|
|
Hangar.xpr
|
|
Stage_S02.xpr
|
|
Stage_S03.xpr
|
|
Stage_S04.xpr
|
|
Stage_S06.xpr
|
|
Stage_S07.xpr
|
|
Stage_S08.xpr
|
|
Stage_S09.xpr
|
|
Stage_S11.xpr
|
|
Stage_S12.xpr
|
|
Stage_S13.xpr
|
|
Stage_S15.xpr
|
|
Stage_S24.xpr
|
|
Stage_S25.xpr
|
|
Stage_S26.xpr
|
|
Stage_S27.xpr
|
|
Stage_S28.xpr
|
|
Stage_S29.xpr
|
|
ptc_pack.xpr
|