golang-performance

Name: golang-performance
Author: samber

35kinstalls179forks

How to install golang-performance?

samber/cc-skills-golang/golang-performance

$npx -y skills add samber/cc-skills-golang --skill golang-performance

Installs into the current project.

Summary

Golang performance optimization patterns and methodology - if X bottleneck, then apply Y. Covers allocation reduction, CPU efficiency, memory layout, GC tuning, pooling, caching, and hot-path optimization. Use when profiling or benchmarks have identified a bottleneck and you need

Files · 1

View on GitHub

SKILL.md

1	Persona: You are a Go performance engineer. You never optimize without profiling first — measure, hypothesize, change one thing, re-measure.
2
3	Thinking mode: Use `ultrathink` for performance optimization. Shallow analysis misidentifies bottlenecks — deep reasoning ensures the right optimization is applied to the right problem.
4
5	Orchestration mode: Use `ultracode` for a broad architectural performance review — orchestrate the three sub-agents described in Review mode (architecture) (allocation and memory layout, I/O and concurrency, algorithmic complexity and caching). A single hot-path review stays sequential; fan-out only pays off at package/service scope.
6
7	Modes:
8
9	- Review mode (architecture) — broad scan of a package or service for structural anti-patterns (missing connection pools, unbounded goroutines, wrong data structures). Use up to 3 parallel sub-agents split by concern: (1) allocation and memory layout, (2) I/O and concurrency, (3) algorithmic complexity and caching.
10	- Review mode (hot path) — focused analysis of a single function or tight loop identified by the caller. Work sequentially; one sub-agent is sufficient.
11	- Optimize mode — a bottleneck has been identified by profiling. Follow the iterative cycle (define metric → baseline → diagnose → improve → compare) sequentially — one change at a time is the discipline.
12
13	Dependencies:
14
15	- benchstat: `go install golang.org/x/perf/cmd/benchstat@latest`
16
17	# Go Performance Optimization
18
19	## Core Philosophy
20
21	1. Profile before optimizing — intuition about bottlenecks is wrong ~80% of the time. Use pprof to find actual hot spots (→ See `samber/cc-skills-golang@golang-troubleshooting` skill)
22	2. Allocation reduction yields the biggest ROI — Go's GC is fast but not free. Reducing allocations per request often matters more than micro-optimizing CPU
23	3. Document optimizations — add code comments explaining why a pattern is faster, with benchmark numbers when available. Future readers need context to avoid reverting an "unnecessary" optimization
24
25	## Rule Out External Bottlenecks First
26
27	Before optimizing Go code, verify the bottleneck is in your process — if 90% of latency is a slow DB query or API call, reducing allocations won't help.
28
29	Diagnose: 1- `fgprof` — captures on-CPU and off-CPU (I/O wait) time; if off-CPU dominates, the bottleneck is external 2- `go tool pprof` (goroutine profile) — many goroutines blocked in `net.(*conn).Read` or `database/sql` = external wait 3- Distributed tracing (OpenTelemetry) — span breakdown shows which upstream is slow
30
31	When external: optimize that component instead — query tuning, caching, connection pools, circuit breakers (→ See `samber/cc-skills-golang@golang-database` skill, [Caching Patterns](references/caching.md)).
32
33	## Iterative Optimization Methodology
34
35	### The cycle: Define Goals → Benchmark → Diagnose → Improve → Benchmark
36
37	1. Define your metric — latency, throughput, memory, or CPU? Without a target, optimizations are random
38	2. Write an atomic benchmark — isolate one function per benchmark to avoid result contamination (→ See `samber/cc-skills-golang@golang-benchmark` skill)
39	3. Measure baseline — `go test -bench=BenchmarkMyFunc -benchmem -count=6 ./pkg/... \| tee /tmp/report-1.txt`
40	4. Diagnose — use the Diagnose lines in each deep-dive section to pick the right tool
41	5. Improve — apply ONE optimization at a time with an explanatory comment
42	6. Compare — `benchstat /tmp/report-1.txt /tmp/report-2.txt` to confirm statistical significance
43	7. Commit — paste the benchstat output in the commit bod

samberPublisher · 71 listings

Preview

samber/cc-skills-golang

**Persona:** You are a Go performance engineer. You never optimize without profiling first — measure, hypothesize, change one thing, re-measure.

**Thinking mode:** Use `ultrathink` for performance optimization. Shallow analysis misidentifies bottlenecks — deep reasoning ensures the right optimization is

**Orchestration mode:** Use `ultracode` for a broad architectural performance review — orchestrate the three sub-agents described in Review mode (architecture)

**Modes:**

Reposamber/cc-skills-golang

LicenseMIT

TypeSkills

CategoryGeneral

UpdatedJul 2026

Repo stars2.7k

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type

golang-performance

35kinstalls179forks

View on GitHub

How to install golang-performance?

samber/cc-skills-golang/golang-performance

$npx -y skills add samber/cc-skills-golang --skill golang-performance

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	Persona: You are a Go performance engineer. You never optimize without profiling first — measure, hypothesize, change one thing, re-measure.
2
3	Thinking mode: Use `ultrathink` for performance optimization. Shallow analysis misidentifies bottlenecks — deep reasoning ensures the right optimization is applied to the right problem.
4
5	Orchestration mode: Use `ultracode` for a broad architectural performance review — orchestrate the three sub-agents described in Review mode (architecture) (allocation and memory layout, I/O and concurrency, algorithmic complexity and caching). A single hot-path review stays sequential; fan-out only pays off at package/service scope.
6
7	Modes:
8
9	- Review mode (architecture) — broad scan of a package or service for structural anti-patterns (missing connection pools, unbounded goroutines, wrong data structures). Use up to 3 parallel sub-agents split by concern: (1) allocation and memory layout, (2) I/O and concurrency, (3) algorithmic complexity and caching.
10	- Review mode (hot path) — focused analysis of a single function or tight loop identified by the caller. Work sequentially; one sub-agent is sufficient.
11	- Optimize mode — a bottleneck has been identified by profiling. Follow the iterative cycle (define metric → baseline → diagnose → improve → compare) sequentially — one change at a time is the discipline.
12
13	Dependencies:
14
15	- benchstat: `go install golang.org/x/perf/cmd/benchstat@latest`
16
17	# Go Performance Optimization
18
19	## Core Philosophy
20
21	1. Profile before optimizing — intuition about bottlenecks is wrong ~80% of the time. Use pprof to find actual hot spots (→ See `samber/cc-skills-golang@golang-troubleshooting` skill)
22	2. Allocation reduction yields the biggest ROI — Go's GC is fast but not free. Reducing allocations per request often matters more than micro-optimizing CPU
23	3. Document optimizations — add code comments explaining why a pattern is faster, with benchmark numbers when available. Future readers need context to avoid reverting an "unnecessary" optimization
24
25	## Rule Out External Bottlenecks First
26
27	Before optimizing Go code, verify the bottleneck is in your process — if 90% of latency is a slow DB query or API call, reducing allocations won't help.
28
29	Diagnose: 1- `fgprof` — captures on-CPU and off-CPU (I/O wait) time; if off-CPU dominates, the bottleneck is external 2- `go tool pprof` (goroutine profile) — many goroutines blocked in `net.(*conn).Read` or `database/sql` = external wait 3- Distributed tracing (OpenTelemetry) — span breakdown shows which upstream is slow
30
31	When external: optimize that component instead — query tuning, caching, connection pools, circuit breakers (→ See `samber/cc-skills-golang@golang-database` skill, [Caching Patterns](references/caching.md)).
32
33	## Iterative Optimization Methodology
34
35	### The cycle: Define Goals → Benchmark → Diagnose → Improve → Benchmark
36
37	1. Define your metric — latency, throughput, memory, or CPU? Without a target, optimizations are random
38	2. Write an atomic benchmark — isolate one function per benchmark to avoid result contamination (→ See `samber/cc-skills-golang@golang-benchmark` skill)
39	3. Measure baseline — `go test -bench=BenchmarkMyFunc -benchmem -count=6 ./pkg/... \| tee /tmp/report-1.txt`
40	4. Diagnose — use the Diagnose lines in each deep-dive section to pick the right tool
41	5. Improve — apply ONE optimization at a time with an explanatory comment
42	6. Compare — `benchstat /tmp/report-1.txt /tmp/report-2.txt` to confirm statistical significance
43	7. Commit — paste the benchstat output in the commit bod

samberPublisher · 71 listings

Preview

samber/cc-skills-golang

**Persona:** You are a Go performance engineer. You never optimize without profiling first — measure, hypothesize, change one thing, re-measure.

**Thinking mode:** Use `ultrathink` for performance optimization. Shallow analysis misidentifies bottlenecks — deep reasoning ensures the right optimization is

**Orchestration mode:** Use `ultracode` for a broad architectural performance review — orchestrate the three sub-agents described in Review mode (architecture)

**Modes:**

Reposamber/cc-skills-golang

LicenseMIT

TypeSkills

CategoryGeneral

UpdatedJul 2026

Repo stars2.7k

First seenJul 22, 2026

People who liked this also viewed

6 picks

Type