"How fast is this?" is one of the most unreliable questions a developer can answer. A single time git commit tells you almost nothing — the first run warms a cache, the second collides with your editor, the third just feels faster because you want it to. Your intuition is doing the measuring, and your intuition is lying.
hyperfine is the correction. It's a command-line benchmarking tool written in Rust by David Peter (you know his other projects: fd, bat, hexyl). You point it at one or more commands, and it runs them many times, then reports the mean with honest error bars. It fixes the two things we all get wrong: too few runs, and cache noise.
It measures like you'd want to
Give it a command and a minimum patience:
hyperfine 'grep -R TODO src'
By default hyperfine does at least 10 runs and keeps going for at least 3 seconds, so a quick cmd like ls gets many more repetitions than a slow one. Across those runs it computes statistics and even flags outliers — a background compile or a GC pause that would have polluted a hand-timed "result" gets surfaced instead of silently averaged in. It also corrects for shell spawn overhead by calibrating startup time with an empty command, so you're measuring the tool, not the sh that launched it.
Want to compare two ways of doing the same job? Pass both:
hyperfine 'jp2' 'jq' 'pup'
You get a table with each command's time, slowdown relative to the fastest, and a bar chart. No more "I tried it and it felt snappier." Now it's in colored bars.
Handling the cache problem
The most common reason a benchmark lies is disk cache state. If the first run handed the OS a warm page cache and the second didn't, you're comparing different machines. hyperfine gives you control:
--warmup 3runs the command a few times before measuring, to fill caches the way a real user would have.--prepare '...'runs a command before each timed run — on Linux you can clear page caches between runs withsync; echo 3 | sudo tee /proc/sys/vm/drop_cachesto force a cold-cache measurement.
There's also --parameter-scan for sweeping a single value. Benchmarking a build across thread counts becomes:
hyperfine --prepare 'make clean' --parameter-scan n 1 8 'make -j {n}'
Saving results, and what's new in 2.0
hyperfine exports to CSV, JSON, Markdown, and AsciiDoc, so your benchmark can live as a table in the commit message or a chart in CI. The Bencher project even wires hyperfine into continuous benchmarking to catch performance regressions automatically.
Version 2.0 landed on October 7, 2026, and it's worth grabbing for one reason: metrics beyond time. By default it now reports peak memory usage next to wall-clock time, and the new --metrics flag can pull CPU cycles, instructions, cache misses, and mispredicted branches — when your hardware provides them. "Faster but uses twice the RAM" is now visible in the same command that shows the speedup.
Two breaking changes if you rely on 1.x: commands run directly now, without an intermediate shell (use -S if you need pipes and wildcards), and the JSON export format changed. Scripts reading results[i].mean will need updating.
Install it however you like — Homebrew, apt, Fedora, or cargo install hyperfine. The name nods to the hyperfine levels of caesium-133, the transition that defines our base unit of time. It's a fitting name for a tool whose whole job is making your time measurements reliable.
Next time you're about to tell a teammate "the new version is faster," run it once with hyperfine first. You might be surprised — that's the point.