Module scheduler_bench 

The scheduler oracle’s driver: run a real [Study] with a scheduler over synthetic curves and record exactly what it pruned.

This is the other half of the scheduler gate. Where harness drives the sampler seam, this drives the whole study loop — because a scheduler is only ever consulted through TrialCtx::report, inside the objective’s inner loop (docs/extending/scheduler.md). So the oracle must run the real loop, let the objective stream a LearningCurve step by step, and honour the prune signal the loop returns.

Why the study loop works here without the system feature

Study::optimize at the default parallelism(1) spawns no threads and catches no panics — the wasm-clean path (docs/extending/objective-and-executor.md) — so this driver also runs against atune_core with default features off when the crate’s host-only overhead feature is disabled. It needs none of that arm’s storage/clock facilities. Single-worker is also what makes the pruning deterministic: a scheduled study is replayable, not pre-determined under parallelism (its prunes depend on completion order), but under one worker with a fixed seed the completion order is fixed, so the whole pruned set is reproducible (docs/concepts/determinism.md).

How a trial is bound to a curve

The objective reads ctx.meta().number and evaluates curves[number]. Trials complete in number order (one worker, no queue), so trial i is curves[i] and completes before trial i + 1 — which is what makes the competitor set a scheduler sees at each decision point knowable, and the whole scenario hand-verifiable.

Structs

BenchReport

The result of driving a whole scenario through one scheduler.

TrialOutcome

What one trial did under the scheduler.

Functions

run

Runs scheduler over curves and records what it pruned.