hyperfoot 0.2.2

Benchmark the resource footprint of commands
hyperfoot-0.2.2 is not a library.

Install

Requires Rust 1.85+ and ~/.cargo/bin on your PATH.

cargo install hyperfoot

Verify:

hyperfoot --help
git clone https://github.com/cesarferreira/hyperfoot.git
cd hyperfoot
cargo install --path . --locked
# or
make install-release

Debug install (faster compile, larger binary):

make install

Run without installing:

make build-release
./target/release/hyperfoot

Quickstart

Report one command's resource footprint:

$ hyperfoot 'cargo build'

Benchmark cargo build

  Time          12.84 s ± 0.31 s
  CPU           624.3 %
  CPU time      78.91 s
  Peak memory   2.14 GB
  Disk read     482.30 MB
  Disk write    127.80 MB
  Processes     43
  Threads       184

  10 runs

Compare two or more commands:

$ hyperfoot 'npm run build' 'bun run build'

┌────────────────┬────────────────┬────────────────┐
                │ npm run build  │ bun run build  │
├────────────────┼────────────────┼────────────────┤
 Time           │ 8.42 s         │ 2.11 s         │
 CPU            │ 483.0 %        │ 612.0 %
 CPU time       │ 40.65 s        │ 12.92 s        │
 Peak memory    │ 1.24 GB        │ 714.00 MB      │
 Disk read      │ 382.00 MB      │ 241.00 MB      │
 Disk write     │ 147.00 MB      │ 89.00 MB       │
 Processes      │ 58             │ 21             │
└────────────────┴────────────────┴────────────────┘

 bun run build
    3.99× faster than npm run build
    42% less memory
    37% less disk reads
    39% less disk writes

Each metric's winning column gets a highlighted background in the real (colored) output — so if one command is faster but uses more memory, that split is obvious at a glance instead of one column sweeping every row.

Other flags:

hyperfoot --runs 20 --warmup 3 'cargo test'                     # more samples, discard the first 3
hyperfoot --prepare 'cargo clean' 'cargo build'                 # reset state before every run
hyperfoot --export-json out.json --export-csv out.csv 'ls'      # machine-readable output

On Linux, when the process's own cgroup v2 subtree is writable (typical under a systemd user session), memory and disk I/O are exact kernel-reported totals instead of estimates from polling — no ~ marker on those lines.

Development

make build-release         # build target/release/hyperfoot
make install                # build + install to ~/.cargo/bin (debug)
make test                   # cargo test
make check                  # cargo check + clippy
make release LEVEL=patch    # bump version, regenerate CHANGELOG.md, tag, publish, push

make release requires cargo-release and git-cliff; pushing the resulting v* tag triggers the release workflow, which builds the multi-platform binaries and publishes a GitHub Release.

License

MIT