Tracing benchmark: 513 versus 115 iterations

513 checks → 115, nice
need runtime + input size too. fewer visited voxels doesn't automatically mean the same factor of speedup

The tiny complexity sheet records exhaustive = 513 and tracing = 115 iterations. The ratio is 513/115 ≈ 4.46; the reduction relative to exhaustive is (513-115)/513 ≈ 77.58%. This matches the poster's rounded 77% statement as a reduction in the recorded iteration count.

Exhaustive versus tracing: 513 and 115 iterations.
Exhaustive versus tracing: 513 and 115 iterations.

It does not establish an asymptotic complexity bound or a 4.46× runtime improvement. The export does not give input size, neighborhood dimensions, hardware, elapsed time, repetitions or a definition of one iteration. A useful next benchmark would retain those fields and vary bottleneck volume/sparsity, logging both visited voxels and wall time.

For code lookup, distinguish the exhaustive neighborhood scan from following connected bottleneck structure. In the poster diagram, “checked voxels” and “bottleneck voxels” are different quantities; recording both would make the pruning mechanism interpretable.