vwemirror/BT411
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Load-time attribution: the minute is the renderers' entity-make streams

Browse Source 
Measured (loadphase markers + queue blocker dump): renderer LoadMission
31ms, model loads 0.2s -- the teal->green minute is the LoadingMission
ready-gate (IsPriorityEmpty counts timed events too) waiting out the
THREE renderers' entity-make streams: every entity/subsystem creation
posts message 3 to each Renderer receiver (classIDs 8/30/36 =
video/audio/gauge), hundreds deep per queue, draining across the whole
window (the audio renderer's share is why sound starts mid-load).

Instrumentation kept: [loadphase] markers (renderer span + busy-pass
counter) always on; GeneralEventQueue::DumpBlockers + the class-named
DumpData fallback behind BT_LOAD_DIAG=1 (hundreds of lines per load).
Optimizing the drain (batching/budget) is an open perf item --
deliberately untouched before the 8-player night.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
arcattack
2026-07-22 20:41:36 -05:00
co-authored by Claude Opus 4.8
parent 0ef5a3c4e1
commit 7b3e76db38
4 changed files with 53 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files
context/multiplayer.md
+12
View File
@@ -437,6 +437,18 @@ phase). Plan: `~/.claude/plans/partitioned-snuggling-piglet.md`.
from take 2's commit is UNPROVEN -- the measured fact is just that loads outlive any fixed
cap; the counter design is correct under either reading. Residual: WHY loads take 1-2+ min
on the operator box (vs ~30s earlier same day) is an open perf question ([loadobj] timings).
- **WHERE THE LOAD MINUTE GOES (2026-07-22) [T2, measured]**: teal->green (egg receipt ->
WaitingForLaunch/READY) measured 58s on the operator box uncontended, ~28s on a quieter run.
Attribution (loadphase markers + queue dump): renderer LoadMission = **31ms**, model loads =
**0.2s** -- essentially ALL the time is the LoadingMission ready-gate
(`CheckLoadMessageHandler` requires `IsPriorityEmpty(MinEventPriority)`, which counts TIMED
events too) waiting out the **three renderers' entity-make streams**: every entity/subsystem
creation posts a make message (message 3) to each Renderer receiver (classIDs 8/30/36 =
video/audio/gauge), hundreds deep per queue, draining over the whole window (the audio
renderer's share is why sound starts mid-load). Optimization (batch the makes / profile
per-event cost) is an OPEN perf item -- deliberately not attempted pre-8-player-night.
Diags: `[loadphase]` markers always on; the full queue dump gates on `BT_LOAD_DIAG=1`;
`GeneralEventQueue::DumpBlockers` + the named fallback in `Event::DumpData`.
- **READY LIGHT (2026-07-22) [T2, live-verified]**: the roster showed "registered" for a
still-loading pod and a ready one alike. When the app ladder reaches WaitingForLaunch
(APP.cpp CheckLoad transition) the pod sends ONE empty route **-10** frame on its live relay