0efd692b4c
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".
79 lines
3.5 KiB
Markdown
79 lines
3.5 KiB
Markdown
# 🟡 `build-reborn test` takes about an hour — and I left two runaways
|
||
|
||
**Status:** ✅ measured. Two facts, one of them my own mess.
|
||
|
||
## The gate the brief names does not complete
|
||
|
||
`build-reborn test` (`cargo test --workspace` with `SYLPHEED_DISC` wired up) is
|
||
the verification gate. It contains a disc test that decodes **every `.xpr` in
|
||
`hidden/resource3d` — 166 files, 1.4 GB** — through the full `Xbg7Model`
|
||
anchoring path:
|
||
|
||
```rust
|
||
#[test] // NOT #[ignore]d
|
||
fn twin_pairs_do_not_share_a_buffer() {
|
||
…for f in &files { … Xbg7Model::anchor_models_cancellable(&bytes, 0.0, &|| false) … }
|
||
```
|
||
|
||
Measured: one instance accumulated **3 h 26 m of CPU at 89 %** without finishing.
|
||
|
||
### 🔴 "Cannot terminate" was too strong — corrected
|
||
|
||
It terminates; it is merely heavy, and I said the stronger thing before measuring
|
||
it. Timing `sylpheed-cli mesh info` on each of the 166 files with a 25 s cap
|
||
([`data/slow-xpr-files.txt`](data/slow-xpr-files.txt)):
|
||
|
||
| | |
|
||
|---|---|
|
||
| files scanned | 166 |
|
||
| exceeding 25 s | **19** — `Hangar`, 17 `Stage_*`, `ptc_pack` |
|
||
| `Stage_S02` timed to completion | **144 s**, `rc = 0` |
|
||
|
||
So nothing hangs. Nineteen heavy containers at roughly two minutes each is
|
||
**~45–60 minutes** for one pass, before the 147 fast ones. The observed 3 h 26 m
|
||
was that work running at a **load average of 9–14** — inflated by my own two
|
||
duplicate runs competing with each other and with this one. The runaways did not
|
||
merely coexist with the slowness; they multiplied it.
|
||
|
||
⚠️ The practical conclusion is unchanged and only the wording softens: an
|
||
hour-scale suite is not an iteration-scale gate.
|
||
Its sibling in the same file, `shared_resources_decode_identically_in_every_container`,
|
||
walks the same 166 files and *is* `#[ignore]`d (as known-failing), so the binary's
|
||
cost is easy to underestimate from a glance at the file.
|
||
|
||
⚠️ **Consequence for anyone using this gate:** every "green run" reported in this
|
||
corpus from a workspace test is necessarily **partial** unless it explicitly says
|
||
the suite terminated. `cargo test -p sylpheed-formats` reaches ~131 tests in a few
|
||
minutes and then sits in this one; the workspace run is the same picture. Quote
|
||
the suite count and the elapsed state, not the word "green".
|
||
|
||
🟡 Not proposed here: `#[ignore]`-ing it, or bounding it to a sample of the 166.
|
||
Both change what the suite asserts, which is the project's call and not a
|
||
side-effect of an audit.
|
||
|
||
## 🔴 And I left two of them running for four hours
|
||
|
||
Two `cargo test -p sylpheed-formats` runs launched detached in earlier iterations
|
||
never exited, because they were sitting in this test. At the moment they were
|
||
found:
|
||
|
||
| pid | elapsed | child | CPU time | %CPU |
|
||
|---|---|---|---|---|
|
||
| 103375 | 4 h 12 m | `mesh_consistency_disc` | **3 h 26 m** | 89.3 |
|
||
| 99965 | 4 h 39 m | `pak_idxd_disc` | 1 h 16 m | 93.8 |
|
||
|
||
Load average **14.18** on 12 cores. Killed; load fell to **9.68** within a
|
||
minute, and the legitimately-running workspace suite was checked first and left
|
||
alone.
|
||
|
||
### 🔴 What this does NOT explain
|
||
|
||
It is tempting to pin the session's emulator troubles on this, and the
|
||
measurement says no. `screenshot` cost **0.49 s** with both runaways live and the
|
||
emulator stopped, against the **10.8 s** measured earlier with the emulator
|
||
running. So the 92× figure in
|
||
[capture-harness-status](capture-harness-status.md) really was emulator
|
||
contention, and the runaways were a background tax on top — not the cause. The
|
||
black surface and the unreachable title stand as measured, with their own
|
||
controls.
|