Golang Benchmark
Write credible Go benchmarks using Go 1.24+ b.Loop() instead of legacy b.N loops and sink hacks.
Overview
golang-benchmark is an agent skill for the Ship phase that teaches Go 1.24+ benchmark patterns centered on b.Loop() with correct setup placement.
Install
npx skills add https://github.com/samber/cc-skills-golang --skill golang-benchmarkWhat is this skill?
- Enforces b.Loop() (Go 1.24+) as the benchmark loop construct
- Places fixture setup before b.Loop() without manual b.ResetTimer()
- Avoids package-level sink variables for dead-code elimination
- Rejects legacy for i := 0; i < b.N and for range b.N patterns
- Includes eval cases for unrealistic ns/op JSON parse benchmarks
- Eval case uses 1MB test fixture for ComputeHash SHA-256 benchmark
- Five assertions in b-loop-vs-range-bn eval for loop and setup rules
Adoption & trust: 3.6k installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent-written Go benchmarks use b.N loops or sinks and report nonsense nanoseconds per operation.
Who is it for?
Indie Go developers on 1.24+ optimizing hot paths who want agent-generated bench code to match current testing.B guidance.
Skip if: Projects still pinned below Go 1.24 where b.Loop() is unavailable, or teams that only need table-driven unit tests.
When should I use this skill?
Writing or reviewing Go benchmarks, especially after upgrading to Go 1.24+ or when bench results look unrealistically fast.
What do I get? / Deliverables
You get benchmarks that use b.Loop(), keep setup outside the loop, and produce believable ops/sec for hash, parse, and CPU-bound paths.
- Benchmark functions using b.Loop()
- Correctly structured setup and measured hot loop
Recommended Skills
Journey fit
Benchmark authoring and regression hygiene belong in Ship’s testing subphase where you prove performance before release, not during first feature scaffolding. Testing subphase covers micro-benchmarks, dead-code elimination pitfalls, and setup placement—exactly what the skill’s assertions target.
How it compares
Opinionated Go bench style skill—not a generic load-testing or profiling MCP integration.
Common Questions / FAQ
Who is golang-benchmark for?
Solo builders writing Go services or CLIs who delegate benchmark files to coding agents and need modern testing.B loops.
When should I use golang-benchmark?
During Ship testing when adding or fixing benchmarks before a performance-sensitive release or when debugging suspiciously fast bench results.
Is golang-benchmark safe to install?
It guides test code generation; review the Security Audits panel on this page and run benchmarks only in trusted environments.
SKILL.md
READMESKILL.md - Golang Benchmark
[ { "id": 1, "name": "b-loop-vs-range-bn", "description": "Tests whether the model uses b.Loop() (Go 1.24+) instead of the legacy for range b.N pattern", "prompt": "Write a Go benchmark for a function `ComputeHash(data []byte) [32]byte` that uses SHA-256. The project uses Go 1.24. Include setup code that loads a 1MB test fixture.", "trap": "Without the skill, the model defaults to `for i := 0; i < b.N; i++` or `for range b.N`, where setup may need manual b.ResetTimer() and unused results may need a sink to prevent dead code elimination", "assertions": [ {"id": "1.1", "text": "Uses b.Loop() as the benchmark loop construct"}, {"id": "1.2", "text": "Setup code (loading fixture) is placed BEFORE the b.Loop() call, not inside it"}, {"id": "1.3", "text": "Does NOT use b.ResetTimer() since b.Loop() automatically excludes setup"}, {"id": "1.4", "text": "Does NOT use a package-level sink variable to prevent dead code elimination"}, {"id": "1.5", "text": "Does NOT use `for i := 0; i < b.N; i++` or `for range b.N`"} ] }, { "id": 2, "name": "dead-code-elimination-awareness", "description": "Tests whether the model understands that b.Loop() prevents compiler dead code elimination", "prompt": "I have this benchmark that seems unrealistically fast — the results show 0.3 ns/op for a function that parses a 10KB JSON document. What's wrong?\n\n```go\nfunc BenchmarkParseJSON(b *testing.B) {\n data := loadFixture(\"large.json\")\n for i := 0; i < b.N; i++ {\n ParseJSON(data)\n }\n}\n```\nThe project uses Go 1.24.", "trap": "Without the skill, the model may suggest adding b.ResetTimer() or increasing benchtime, missing the core issue of dead code elimination", "assertions": [ {"id": "2.1", "text": "Identifies dead code elimination as the cause — the compiler optimizes away the ParseJSON call because its result is unused"}, {"id": "2.2", "text": "Recommends migrating to b.Loop() as the primary fix since it prevents DCE automatically"}, {"id": "2.3", "text": "If mentioning the legacy workaround, describes using a package-level sink variable (not a local one)"}, {"id": "2.4", "text": "Explains that b.Loop() also automatically excludes the setup code from timing"} ] }, { "id": 3, "name": "count-flag-statistical-significance", "description": "Tests whether the model recommends -count=10 for statistical significance rather than single runs", "prompt": "I want to compare the performance of two JSON serialization approaches. How should I run the benchmarks to get reliable comparison data?", "trap": "Without the skill, the model may suggest a single `go test -bench=.` run per version without -count, making benchstat comparison impossible", "assertions": [ {"id": "3.1", "text": "Recommends -count=10 (or higher) for statistical significance"}, {"id": "3.2", "text": "Recommends using benchstat to compare the two runs"}, {"id": "3.3", "text": "Recommends -benchmem to track allocation metrics"}, {"id": "3.4", "text": "Recommends saving output to files (e.g., via tee) for later benchstat comparison"}, {"id": "3.5", "text": "Uses -run='^$' to skip unit tests during benchmark runs"} ] }, { "id": 4, "name": "benchstat-output-interpretation", "description": "Tests understanding of benchstat output format including p-value, tilde symbol, and confidence intervals", "prompt": "I ran benchstat and got this output. What does it mean? Should I merge my optimization?\n\n```\n │ old.txt │ new.txt │\n │ sec/op │ sec/op vs base │\nParse-16 4.592µ ± 8% 4.481µ ± 7% ~ (p=0.089 n=10)\n```", "trap": "Without the skill, the model may interpret the lower number as an improvement and recommend merging", "assertions": [ {"id": "4.1", "text": "Explains that the ~ symbol means no stat