Three orchestration findings on the parked PERF item, none measured yet:
1. The perf A/B needs no new code -- two Insights traces on a deterministic
world are a clean before/after. But tile skipping changes how many times
GenerateMesh runs, so totals conflate "cheaper per tile" with "fewer
tiles". TilesMeshed from task 001 is the denominator. 001 is therefore a
PREREQUISITE for the perf work, not a parallel item as the handoff had it.
2. The suspects don't share an archetype: SurfaceWorld is the column memo,
TunnelNetwork is 19 virtual calls per voxel (16 + 3 structural post).
One lumped number can't be acted on -- measure one strate at a time.
3. GetColumn is a direct-mapped hashed table where GSurfColCache is a
direct-indexed box, and the mesher pre-samples Z-OUTERMOST (verified,
VoxelMarchingCubesMesher.cpp ~226) so every column is revisited ~34x per
tile. The table's sizing comment reasons about fullness; a direct-mapped
table evicts on collision. At load factor 0.28 that is still ~25% of
columns recomputing the full height stack every Z plane -- derived ~9x.
Task 002 measures that and fixes nothing, so the instrument and the fix
cannot land in the same build and make each other unreadable.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
