SetShardCount allocated and zeroed three per-pixel accumulators for every shard up front. With a
GPU present none of them is ever written - the frames are decoded and folded on the device - and on
a 16 Mpx detector eight shards are 2.9 GB to allocate and clear, measured at 0.8 s of the pre-scan
spent on memory nothing reads.
A shard now allocates on the first frame that reaches it, and the fold skips shards that never got
one.
Two things that go with it, not in the version on 2608-performance. Reduce's single-shard fast path
returns that shard directly, which is now an EMPTY projection if nothing was ever added to it,
where before it was a zeroed full-size one - and both callers index it by pixel. The fast path
therefore requires the shard to hold at least one frame; otherwise the general path builds the
zeroed projection as before. Also drops a duplicate include of ParallelFor.h.
Split out of "Find the first pass's spots on every worker", which carried it as an unrelated rider.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011n8riB6X59oRjkrSHzNPAU
