Interface BenchOptions

Executes tasks concurrently based on the specified concurrency mode.

• When mode is set to null (default), concurrency is disabled.
• When mode is set to 'task', each task's iterations (calls of a task function) run concurrently.
• When mode is set to 'bench', different tasks within the bench run concurrently.

Minimum iterations per task in sequential modes (null and 'bench'). With concurrency: 'task', a positive value instead caps scheduled iterations; scheduling stops when either positive iteration or time limit is reached. Zero disables this limit in that mode and requires a finite threshold (for example, threshold: 10), not the default Infinity.

Benchmark name.

Function to get the current timestamp in milliseconds.

Keep samples for statistics calculation

Setup function to run before each benchmark task (cycle)

An AbortSignal for aborting the benchmark.

Whether to subtract an estimated timestamp provider call overhead from each raw latency sample.

Each sample is measured as t1 - t0 around a single call to the task function, so every raw sample is inflated by approximately one timestamp provider call cost C. When this option is true, an estimate Ĉ is computed once at construction time via calibrateTimerOverhead, and max(0, raw_sample - Ĉ) is used in place of each non-overridden sample before statistics are computed.

Statistics after correction. Statistics use the final samples, after correction and any duration overrides. When all latency samples are timer-measured and exceed Ĉ, subtracting the constant shifts location statistics by Ĉ while leaving variance and absolute dispersion unchanged apart from rounding. Relative error can increase as the mean decreases.

When samples clamp to zero, these translation rules no longer hold. Quantiles are interpolated: exactly half zero samples need not give a zero median, and a zero median does not imply zero mean absolute deviation. Prefer overriddenDuration for sub-overhead measurements.

Three observable consequences of the clamp.

1. latency.min may be exactly 0 even when no zero-duration sample was actually observed.
2. The throughput estimator substitutes 1000 / latency.mean (or 0 when mean === 0) for every clamped sample.
3. detectTimerSaturation criterion 'zero-dominated' cannot distinguish clamped samples from genuine zero-duration timer reads, so a 'warning' event may be dispatched in the sub-overhead regime even when the timer itself is not saturated.

Caveat — concurrency: "task". The overhead is calibrated once at construction time with sequential timer calls. Setting both options causes the constructor (and run()) to throw, since the sequentially-calibrated estimate would not reflect the per-iteration timer call cost under concurrent execution.

Caveat — overriddenDuration. Samples returned by the task function via overriddenDuration are intentional user values and are never modified by the correction. They are also excluded from Task.detectedResolution and from timer-saturation detection.

If fewer than half of the calibration pairs have positive deltas, the estimate is 0 and the correction is a no-op.

Teardown function to run after each benchmark task (cycle).

Maximum concurrent iterations within a task. Only applies with concurrency: 'task'; does not limit concurrent benchmark tasks. A finite value is required for a task-concurrent cycle with a zero iteration limit (iterations for run or warmupIterations for warmup).

Throws if a task fails.

Time budget per task in milliseconds. Sequential modes keep running until both this budget and the minimum iteration count are met. With concurrency: 'task', a positive finite value instead limits scheduling by elapsed time; reaching either positive limit stops new iterations.

The timestamp provider used by the benchmark. By default 'performance.now' will be used.

Warmup benchmark.

Warmup iteration limit. Task.warmup uses the mode-dependent semantics of iterations; Task.warmupSync always treats this as a minimum.

Warmup time budget in milliseconds. Task.warmup uses the mode-dependent semantics of time; Task.warmupSync always uses the sequential budget.