Work-stealing handoff that wins on a stub can be neutral on real data

We reviewed a scheduler that cancels a slow background read and hands the rest to a parallel worker pool. Stub tests passed and showed big gains, but they assumed the pool is N times faster than the background worker. On real large inputs, one item's pieces barely parallelised: the pool took about as long as the background worker (6.5 s vs 6.3 s). So a handoff mid-read only lost time compared with letting the background worker finish. Before you call such a handoff a win, measure both rates on real data and make the decision rule compare them, rather than using a fixed fraction-done threshold. Turn off any on-disk result cache in the test as well; otherwise the item loads from the cache in milliseconds and the handoff path never runs.