What is going on
cartograph() in tools/argus_mcp/src/cartograph.rs (343 to 371) calls read_bsp29 at 346 before it consults ATLAS_CACHE at 354, so the cache only saves atlas_from_bsp; the planes, nodes, leaves and clipnodes of a 1 to 2 MB file are parsed on every call.
brief_run in intel.rs calls cartograph twice (attach_atlas 1341, attach_item_control 1704) and hull0_for_map (586 to 589) parses the BSP a third time. attach_nav (1302 to 1307) and attach_coverage (1492 to 1497) re-read and re-parse the nav json instead of using nav_graph::load_nav's mtime cache. A soak iteration's compare_runs_scaled does all of that twice.
qc_index.rs: look_at (340 to 352) rebuilds the full 15 file index per call, and brief_run and compare_runs_inner call it once per next step (intel.rs 605 to 607, 1179 to 1181). callers_of (150 to 166) re-reads the file and slice_function joins from the function start to EOF for every indexed function, so one see what=fn builds tens of MB of strings over a 300 KB argus.qc.
Why it matters
Severity medium. This is the heavy path behind briefs and the not reproducible #9 timeout.
How to see it
Time brief_run on a 300 s dm4 tape with and without the atlas cache warm; it barely moves.
What I want
Check the cache before reading the BSP, cache the parsed Bsp29 by mtime, reuse load_nav, build the QC index once per process and invalidate on mtime.
What is going on
cartograph()intools/argus_mcp/src/cartograph.rs(343 to 371) callsread_bsp29at 346 before it consultsATLAS_CACHEat 354, so the cache only savesatlas_from_bsp; the planes, nodes, leaves and clipnodes of a 1 to 2 MB file are parsed on every call.brief_runinintel.rscallscartographtwice (attach_atlas1341,attach_item_control1704) andhull0_for_map(586 to 589) parses the BSP a third time.attach_nav(1302 to 1307) andattach_coverage(1492 to 1497) re-read and re-parse the nav json instead of usingnav_graph::load_nav's mtime cache. A soak iteration'scompare_runs_scaleddoes all of that twice.qc_index.rs:look_at(340 to 352) rebuilds the full 15 file index per call, andbrief_runandcompare_runs_innercall it once per next step (intel.rs605 to 607, 1179 to 1181).callers_of(150 to 166) re-reads the file andslice_functionjoins from the function start to EOF for every indexed function, so onesee what=fnbuilds tens of MB of strings over a 300 KBargus.qc.Why it matters
Severity medium. This is the heavy path behind briefs and the not reproducible #9 timeout.
How to see it
Time
brief_runon a 300 s dm4 tape with and without the atlas cache warm; it barely moves.What I want
Check the cache before reading the BSP, cache the parsed
Bsp29by mtime, reuseload_nav, build the QC index once per process and invalidate on mtime.