hyperfine runs your command without a shell by default, and that changes how you write benchmarks

Run counts are chosen for you: at least 10, aiming for about 3 seconds

The simplest call is hyperfine followed by one or more commands:

hyperfine 'sleep 0.3'

hyperfine decides how many times to run each command. It performs at least 10 benchmarking runs and estimates a run count that targets roughly 3 seconds in total, and that budget includes shell overhead plus any preparation and conclusion commands. While it works, it shows constant feedback on progress and the current estimate, then reports statistics across all runs, with outlier detection to flag interference from other programs and caching effects.

When you need a fixed count, for instance to keep CI time predictable, -r or --runs overrides the estimate:

hyperfine --runs 5 'sleep 0.3'

The trade is statistical: five runs of a noisy command give a weaker estimate than the automatic count would, so use a fixed number for budget reasons, not to make results look tighter.

The first command is the baseline every other result is measured against

Passing several commands turns a benchmark into a comparison:

hyperfine 'hexdump file' 'xxd file'

Commands run and appear in the order you type them. The first one becomes the reference, and each later result is shown as a change relative to it. That ordering is easy to get backwards: if you put the new candidate first and the old version second, the report frames the old program as the change. Put the version you are trying to beat first.

Results can leave the terminal in CSV, JSON, Markdown or AsciiDoc, which covers pasting a table into a pull request or feeding numbers into a script. hyperfine is listed as cross-platform, and on Windows its platform shell is cmd.exe rather than sh, which matters for the shell behaviour below.

Pipes, globs and ~ are not interpreted unless you pass -S

By default hyperfine executes benchmarked commands directly, including warmup runs, which is the --shell=none mode. Arguments are split with shell-like quoting, so quoted arguments containing spaces still work, but pipes, redirections, environment variable expansion, * and ~ are not interpreted. A command like grep -R TODO * would receive a literal asterisk. The reason for this default is accuracy: skipping shell startup removes overhead and the noise of correcting for it, which matters most for fast commands under 5 ms.

If a command contains a standalone shell operator such as && or > without quotes, hyperfine makes you choose. -S, an alias for --shell=default, interprets shell syntax using sh from PATH on Unix or cmd.exe on Windows. -N, an alias for --shell=none, passes the operators as literal arguments.

hyperfine -S 'sleep 0.1 && echo done'

--shell zsh or another name picks a specific shell. When a shell is in use, hyperfine runs it with an empty command several times, measures that startup cost and subtracts it from each measurement.

Setup and prepare hooks always go through a shell

The direct-execution default applies only to the commands being measured. The --setup, --prepare, --conclude and --cleanup hooks always run through a shell: the one picked by --shell, or the platform shell when --shell is omitted or set to none. That asymmetry is deliberate, since hooks are not timed and often need pipes, but it means a hook that relies on bash or zsh syntax will fail under plain sh unless you set --shell.

Shell functions follow the same logic. In bash you can export one and benchmark it by name:

my_function() { sleep 1; }
export -f my_function
hyperfine --shell=bash my_function

In other shells, inline the definition into the command and pass -S. For per-run uniqueness, the zero-based $HYPERFINE_ITERATION variable is exposed inside the benchmarked command, which lets each run write its own log file.

Warm cache with --warmup, cold cache with --prepare and sudo

Programs that do heavy disk I/O produce very different numbers depending on whether the disk cache is warm or cold, and hyperfine leaves that choice to you. For a warm cache, -w or --warmup runs the program a set number of times before measuring:

hyperfine -S --warmup 3 'grep -R TODO *'

For a cold cache, -p or --prepare runs a command before each timed run. On Linux, dropping the filesystem caches takes root:

hyperfine -S --prepare 'sync; echo 3 | sudo tee /proc/sys/vm/drop_caches' 'grep -R TODO *'

Call sudo -v first so the prepare step does not stop to ask for a password mid-benchmark. This recipe is Linux specific, because it writes to /proc/sys/vm/drop_caches; macOS and Windows users need their own cache-clearing command. Leaving out both options means the cache state is whatever the previous run left behind, and the result partly measures that.

Parameter scans cover thread counts, compilers and Git branches

-P or --parameter-scan varies one numeric value across a range and substitutes it into the command:

hyperfine --prepare 'make clean' --parameter-scan num_threads 1 12 'make -j {num_threads}'

Decimal ranges work too, and -D or --parameter-step-size sets the increment, so a delay scan from 0.3 to 0.7 with step 0.2 runs sleep 0.3, sleep 0.5 and sleep 0.7. For non-numeric values, -L or --parameter-list takes a comma separated list:

hyperfine -L compiler g++,clang++ '{compiler} -O2 main.cpp'

Comparing branches combines a list with --setup, so git switch runs once before each set of runs and is kept out of the timing. --env sets variables for benchmarks and their hooks with shell-style quoting but no shell expansion, and placeholders work inside it, so -P threads 1 8 with --env 'OMP_NUM_THREADS={threads}' scans thread counts without editing the program.

--metrics replaces wall-clock time and peak memory with what you choose

Out of the box, hyperfine reports wall-clock time and memory usage, the pair time_wall_clock,memory_peak_resident. --metrics takes a comma separated list instead, and each entry can carry a unit:

hyperfine \
    --metrics memory_peak_resident:MiB,time_wall_clock:ms,instructions \
    './baseline' './candidate'

The instructions metric draws on hardware counters, which hyperfine lists among its supported metrics. Adding instructions next to wall time gives a second view of the same run, but it still says nothing about which function inside the program spends them. hyperfine stays at the level of whole commands.

The project is released under Apache-2.0. The 2.0.0 release arrived on 7 October 2026 after two alpha tags in the preceding two days, and the repository saw its last push on 1 November 2026.

Editorial conclusion

hyperfine suits developers who want to compare command line programs, build flags, thread counts or Git branches with repeated runs and statistics instead of a single time call. It is not a profiler and will not tell you where time goes inside a program, and it cannot remove interference from a noisy machine on its own. Before trusting numbers, decide whether each command needs a shell (-S) or should run directly, whether the cache should be warm (--warmup) or cold (--prepare), and check that scripts written for earlier releases still behave the same under the 2.0.0 release from 7 October 2026.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. sharkdp/hyperfine on GitHub