Parser Guide
Vizb supports multiple benchmark frameworks through its parser registry. Use --parser to select the right one for your benchmark output.
Why Multiple Parsers
Section titled “Why Multiple Parsers”Each benchmark framework produces output in a different format. Vizb’s parser registry knows how to read them all and convert the results into a common structure — so your charts, grouping, filtering, and merging work identically regardless of where the benchmarks came from.
Choosing a Parser
Section titled “Choosing a Parser”Default parser. Reads go test -bench text or -json output.
go test -bench . | vizb -o output.html# or explicitlygo test -bench . | vizb --parser go -o output.htmlWhen JSON auto-detection applies: --parser go is required for JSON input (the go test -bench -json format).
Metrics extracted:
| Metric | Description |
|---|---|
| Execution time | ns/op, with configurable unit |
| Memory | B/op, with configurable unit |
| Allocations | allocs/op, with configurable unit |
| Throughput | MB/s, B/s, GB/s, or custom |
| Iterations | Number of iterations run |
Parses cargo bench output from Criterion.
cargo bench | vizb --parser rs:criterion -o output.htmlMetrics extracted:
| Metric | Description |
|---|---|
| Latency avg | Mean time per iteration |
| Latency lower | Lower bound of confidence interval |
| Latency upper | Upper bound (±) |
Parses cargo bench output from Divan.
cargo bench | vizb --parser rs:divan -o output.htmlMetrics extracted:
| Metric | Description |
|---|---|
| Latency fastest | Fastest measured iteration |
| Latency slowest | Slowest measured iteration (±) |
| Latency median | Median across all samples |
| Latency mean | Mean across all samples |
| Samples | Number of samples collected |
Parses vitest bench output.
npx vitest bench | vizb --parser js:vitest -o output.htmlMetrics extracted:
| Metric | Description |
|---|---|
| Throughput | Operations per second (ops/s) |
| Latency min / max | Fastest and slowest run |
| Latency avg | Mean across all runs |
| Latency p75 / p99 / p995 / p999 | Percentile latency |
| RME | Relative margin of error (±) |
| Samples | Number of samples collected |
Naming convention: When describe() wraps bench() blocks, names are concatenated with /:
describe('n=100', () => { bench('bubbleSort', () => { ... }) bench('insertionSort', () => { ... })})Produces names n=100/bubbleSort and n=100/insertionSort. Use --group-pattern with any valid 2D combination (n/x, n/y, x/n, y/n, x/y, y/x) to split the suite name into its own dimension.
See the Grouping Guide for detailed pattern and regex syntax.
Parses Tinybench console.table() output.
node bench.js | vizb --parser js:tinybench -o output.htmlMetrics extracted:
| Metric | Description |
|---|---|
| Latency avg / med | Mean and median latency |
| Latency RME / MAD | Relative margin of error and median absolute deviation (±) |
| Throughput avg / med | Mean and median operations per second |
| Throughput RME / MAD | Relative margin of error (±) |
| Samples | Number of samples collected |
All Parser Keys
Section titled “All Parser Keys”| Key | Framework | Language |
|---|---|---|
go | Go testing (benchfmt) | Go |
rs:criterion | Criterion | Rust |
rs:divan | Divan | Rust |
js:vitest | Vitest | JavaScript / TypeScript |
js:tinybench | Tinybench | JavaScript / TypeScript |
Add a New Parser
Section titled “Add a New Parser”Want to add support for a benchmark framework or language not listed here? Parser contributions are welcome. Here’s what the process looks like:
- Choose a key following the
<lang>:<framework>convention (e.g.,py:pytest,java:jmh) - Implement a parse function that extracts
[]shared.BenchmarkDatafrom the framework’s output - Register it via
parser.Register("your-key", YourParseFunc)in aninit()block - Add tests with real output samples and edge cases
- Open a PR on GitHub — the existing parsers in
pkg/parser/are good references to follow