feat: expose detected timer resolution per task#570
Closed
jerome-benoit wants to merge 1 commit into
Closed
Conversation
Add a Task.detectedResolution getter (number | undefined) populated after each run with the smallest strictly positive latency sample observed. It is undefined before the first successful run, when all samples are zero (timer too coarse to resolve any iteration), or after Task#reset(). A new estimateResolution helper is exported from src/utils.ts and from the public entry point. The implementation is purely additive: no new option, no behavior change for existing benchmarks.
commit: |
This was referenced May 30, 2026
Collaborator
Author
|
Closed in favor of #571 which consolidates this feature with #568 and #569. The audit found that |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Add a
Task.detectedResolutiongetter (number | undefined) populated after each run with the smallest strictly positive latency sample observed. A newestimateResolutionhelper is exported fromsrc/utils.tsand from the public entry point.Semantics
task.detectedResolutionis:undefinedbefore the first successful runundefinedwhen all samples of the last run were zero (timer too coarse to resolve any iteration)undefinedaftertask.reset()The smallest non-zero sample is a conservative upper bound on the effective timer resolution: a timer of resolution
Rcannot return a non-zero delta smaller thanR. It is more reliable than a nominal value carried by theTimestampProviderbecause it observes the actual resolution at the moment of measurement (subject to OS scheduler jitter, power-saving modes, etc.).Implementation
estimateResolutionis a single linear scan; the cost is negligible relative to a benchmark run. The diagnostic is always populated — no new option, no opt-in. Useful for users who want to interpretlatency.meanhonestly for sub-µs functions, or to feed downstream guards (e.g. a CI that fails whendetectedResolution > Xdue to a degraded environment).Risk
None — purely additive: new public getter on
Task, new export in the entry point. No change to existing options, types, or measurement behavior.