benchmark

Measures latency, throughput, size, and memory with reproducible benchmark workflows.

5|Updated Jan 31, 2026
One-click install
npx skills add https://github.com/nuggocto/dotfiles --skill benchmark-nuggocto
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: benchmark
Source: https://github.com/nuggocto/dotfiles/tree/main/opencode/skills/benchmark
Command: npx skills add https://github.com/nuggocto/dotfiles --skill benchmark-nuggocto

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Performance claims are often based on vibes, debug builds, or single lucky runs. This Skill turns benchmarking into a controlled experiment: it defines the workload, stabilizes the environment, collects enough independent samples, and reports results with uncertainty and caveats so performance decisions are trustworthy. ## Core Features & Use Cases - Rigorous Measurement Discipline: Enforces production-equivalent builds, warm-up, independent runs, and harness-native statistics instead of averages or single samples. - Full Metric Coverage: Guides capture of latency p50/p95/p99, throughput, error rate, CPU, memory, allocations, binary/bundle/image size, and cold vs warm startup. - Regression Comparison: Compares baseline and candidate under identical conditions with predeclared thresholds, randomized run order, and a structured report template. - Use Case: Before merging a pull request that rewrites a hot parsing function, use this Skill to run a Criterion microbenchmark plus a hyperfine CLI comparison, then report whether the change beats the noise floor with p99 and binary size included. ## Quick Start Ask the agent to benchmark the current change against the main branch and report p50, p95, p99 latency, throughput, and binary size with exact commands and environment details.

Frequently Asked Questions about benchmark

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I benchmark code changes before merging?

Build production-equivalent artifacts for both baseline and candidate, then run them under identical workloads, hardware, and flags with randomized or interleaved run order. Compare against a predeclared regression threshold and report the effect size with harness-native uncertainty or run-to-run variability.

What tools should I use for HTTP load testing?

Common choices include oha, wrk2, vegeta, k6, autocannon, and fortio, depending on whether you need open or closed load models. Report target and achieved arrival rate, errors, and the full latency distribution rather than averages.

Why is my p99 latency measurement unreliable?

Tail percentiles need enough observations beyond the target percentile and cannot be derived from mean and standard deviation. Use raw samples or HDR histograms, report sample counts, and never average per-run percentiles.

Can I benchmark debug builds or dev servers?

No, unless that mode is what ships or is the explicit subject of measurement. Debug builds, hot-reload modes, and build-tool wrapper overhead distort results; always match the production compiler, runtime options, and deployment constraints.

When should I use profiling instead of benchmarking?

Profiling explains why a result occurred by showing CPU, memory, or allocation hotspots, but it can perturb timing. Use benchmarks to decide whether a change is faster, then profile separately to locate the bottleneck, and validate claims with an unprofiled run.