tdulcet / benchmarking-tool Goto Github PK

I guess it happens if there are more than 1000 runs?

The outlier detection seems to report a lot of outliers, even for commands that have a really well defined runtime:

▶ bash time.sh -j test.json 'sleep 0.1'
Benchmark #1: sleep 0.1
  Time (x̅ mean ± σ std dev):      0.1019s ±  0.0006s          [User: 0.0014s, System: 0.0004s]
  Range (min … x̃ median … max):   0.101s …  0.102s …  0.103s   CPU:   1.8%, 29 runs

Warning: 10 statistical outlier(s) were detected (> 14.826 modified Z-scores or about 10σ std devs). Consider re-running this benchmark on a quiet system without any interferences from other programs. It might help to use the warmup or prepare options.

The actual times are:

{
  "results": [
    {
      "command": "sleep 0.1",
      "mean": 0.101862068965517,
      "stddev": 0.000570791219210244,
      "median": 0.102,
      "user": 0.00144827586206897,
      "system": 0.000413793103448276,
      "min": 0.101,
      "max": 0.103,
      "times": [
        0.102,
        0.102,
        0.102,
        0.102,
        0.102,
        0.102,
        0.102,
        0.102,
        0.102,
        0.103,
        0.102,
        0.102,
        0.101,
        0.101,
        0.102,
        0.103,
        0.101,
        0.103,
        0.101,
        0.102,
        0.102,
        0.102,
        0.102,
        0.101,
        0.102,
        0.102,
        0.102,
        0.101,
        0.101
      ]
    }
  ]
}

For extremely fast commands, this can happen:

▶ bash /tmp/time.sh "echo a" "echo b"
Benchmark #1: echo a
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted                               ]
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
  Time (x̅ mean ± σ std dev):      0.0000s ±  0.0000s          [User: 0.0000s, System: 0.0000s]
  Range (min … x̃ median … max):   0.000s …  0.000s …  0.000s   CPU:   0.0%, 10 runs

Warning: 10 run(s) of this command took less than 0.005 seconds to complete. Results might be inaccurate.

Benchmark #2: echo b
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted                               ]
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
  Time (x̅ mean ± σ std dev):      0.0000s ±  0.0000s          [User: 0.0000s, System: 0.0000s]
  Range (min … x̃ median … max):   0.000s …  0.000s …  0.000s   CPU:   0.0%, 10 runs

Warning: 10 run(s) of this command took less than 0.005 seconds to complete. Results might be inaccurate.

Summary
  #1 ‘echo a’ ran
awk: cmd. line:1: (FILENAME=- FNR=1) fatal: division by zero attempted
    0.000 ± 0.000 times (0.0%) faster than #2 ‘echo b’

Hi!

Author of hyperfine here. Glad to see that you liked our tool and decided to port it to bash. I have a few questions regarding the statements in the README. Not because I want to claim they are wrong, but because I'm genuinely curious:

produces the same output (with some improvements)

What would be some of these improvements? Maybe we could profit from these in hyperfine as well?

Outputs most of the numbers with greater precision

hyperfine reports all times in millisecond resolution because I don't know how to make a measurement that would be more precise. There is no sense in showing more digits if the actual measurement is not that precise. The problem is that we are spawning an intermediate shell that takes roughly 5 milliseconds on its own. We subtract that time again, but we can not expect to measure microsecond-resolution execution times on top of a 4.8 ms ± 3.7 ms shell spawning time. This is why hyperfine also shows a warning if commands take less than 5 ms to complete.

To get more precise timings, we would need to get rid of the intermediate shell. This is possible in principle, but would keep us from (easily) running benchmarks like seq 100000 | factor.

and outputs more information.

What kind of information would that be? CPU usage?

Supports outputting in ASCII only (no Unicode characters) to support older terminals.

Nice!

Slightly faster when interactive output (the progress bar) is disabled.

Slightly faster than what?

Not really a big problem (mostly a curiosity, if you will), but something that I also fixed in hyperfine at some point. Try:

bash /tmp/time.sh read