BenchmarkResultSink

A destination that receives a benchmark experiment's results as each problem completes rather than in one call at the end.

Why this exists. BenchmarkExperiment.run() builds every problem's result in memory and returns one summary, so a study held its entire output in heap and wrote once. An interruption at hour 30 of a 32-hour run lost all of it — and the checkpointing the class documents works by splitting a study into several experiments over disjoint macro-replication ranges, which does nothing for a study that is a single experiment.

runProblem already completes a problem entirely — cells, confirmation and verification — before the next begins, so the checkpoint boundary exists in the control flow and needs no restructuring to use. Six problems become six checkpoints instead of one, and an interruption costs at most one problem.

Ordering. Exactly one beginExperiment, then zero or more problemCompleted in problem order, then one endExperiment. An interrupted run stops partway and never calls endExperiment, which is how completedProblems can tell an unfinished experiment from a finished one.

Threading. Every call arrives on the thread that invoked run(), serialized between problems. An implementation needs no synchronization of its own.

Inheritors