You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Exploring benchmarks, I was exploring setting Benchmark.defaultConfiguration.timeUnits = .microseconds. It does exactly what it says for the metric Time (wall clock), but doesn't appear to do anything with Time (system CPU) (μs), Time (total CPU) (μs), or Time (user CPU) (μs). And in some cases, I'm seeing the Time (system CPU) come back in ns regardless of what I've chosen.
I suspect it'll be a little easier to track if you can either nail is down explicitly across the board (and sometimes forcing a "round to 0" result), or just letting them float with whatever comes back from the metric gathering system and floating with the relevant range.
The text was updated successfully, but these errors were encountered:
…, improve debugging (#76)
## Description
Fixes#66Fixes#68Fixes#71
Adds regex filtering to debug runs, make CPU time units conform to user
specified time unit also for cpu total/user/cpu times. Add `--scale`
option to command line to get output scaled to per-subiteration values.
Exploring benchmarks, I was exploring setting
Benchmark.defaultConfiguration.timeUnits = .microseconds
. It does exactly what it says for the metric Time (wall clock), but doesn't appear to do anything with Time (system CPU) (μs), Time (total CPU) (μs), or Time (user CPU) (μs). And in some cases, I'm seeing the Time (system CPU) come back in ns regardless of what I've chosen.I suspect it'll be a little easier to track if you can either nail is down explicitly across the board (and sometimes forcing a "round to 0" result), or just letting them float with whatever comes back from the metric gathering system and floating with the relevant range.
The text was updated successfully, but these errors were encountered: