Both passes of the gather are chunked over OUTCOMES, one per frame, but their cost is
the tens of thousands of reflections inside each. ThreadsForWork was being asked about
the frames: a rotation dataset has on the order of a thousand of them against a floor
of 32768 items per thread, so it answered 1, and the pass that walks every reflection
in the run ran on a single thread on every dataset in the test set.
RotationScaleMerge::Ingest does the identical thing and asks with the observation
count, which is what makes this an inconsistency rather than a tuning choice. The
reflection total is already to hand a few lines up.
The split is unchanged - only the worker count moves - so the output is identical.
Measured on the heaviest crystal: the phase drops 33 %, from 8.6 s to 5.5 s, and its
mean occupancy goes from 4.1 threads to 12.3.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
