cpp-optimizer

---
name: cpp-optimizer
description: Audit and optimize C++23 codebases (GCC 16, Clang 22, MSVC 14.52, CMake) for build flags/LTO/PGO, RAII and smart-pointer ownership, copies/moves and allocations, cache locality and data layout, threading/atomics/coroutines, I/O and formatting, UB/sanitizers/hardening, and profiling, with real before/after measurement. Always produces a written findings report and a fix plan for approval before touching code. Use this whenever the user mentions slow C++, memory growth, `shared_ptr` cycles, copies in hot loops, CMake flags, LTO/PGO, ASan/TSan, C++23/C++26, or "optimize my C++ code" -- even if they never say audit or optimize.
---

# C++ Optimizer

C++ performance is ownership, data layout and build flags. The published standard is C++23 (ISO/IEC 14882:2024); C++26 was finalized by WG21 in March 2026 but failed its ISO DIS ballot in October 2026, so treat `-std=c++26` as experimental. Optimize release builds, remove copies/allocations, and make concurrency explicit.

## Workflow

### 1. Scope (quick)

- Find the project root and record the toolchain: C++ standard/compiler, CMake presets, build type/flags, standard library, sanitizer/hardening setup, threading/coroutines, and target ABI.
- Run `python <skill-dir>/scripts/audit.py <project-root>` -- static scan of build files and sources for legacy standards, debug flags, raw ownership, copies/allocations, shared_ptr cycles, data races, iostream/format cost, missing sanitizers, with file:line evidence. Use `--json` to post-process.
- Classify the pain: throughput/latency, memory growth, CPU saturation, concurrency/correctness, I/O or database cost, build/startup, or safety/maintenance. Ask which hurts if unclear.
- Read `references/tooling.md` once: what can be measured here.

### 2. Audit

The script finds cheap leads; you find the rest by reading the hot path and the build. Read the build manifest, entrypoint, the 3-5 hot functions/endpoints and the data layer. Load only what applies:

| Build, toolchain and runtime | `references/build-runtime.md` |
| Memory, ownership and concurrency | `references/memory-concurrency.md` |
| I/O, formatting and data | `references/io-data.md` |
| Safety and quality | `references/safety-quality.md` |
| Measurement | `references/tooling.md` |

**Measure, never guess.** Build with production settings, run with production data/load, and profile that. Debug builds, dev servers and a single request are not evidence. Take a profile before micro-optimizing and a heap/allocator snapshot before raising limits.

Mark each finding **Confirmed** (profile/load/code evidence) or **Suspected** (needs measuring).

### 3. Report

Fill `assets/report-template.md`, save it as `C++_OPTIMIZATION_REPORT.md` in the project root, and show the user. Five-line summary, findings table by impact/effort, then per-finding detail (evidence, why it hurts, fix, risk, behavior impact). Group near-duplicates.

### 4. Plan -- then stop for approval

Use plan mode: `EnterPlanMode` (load with ToolSearch if deferred), write the plan, present with `ExitPlanMode`; if unavailable show it in chat and wait for an explicit "go". Structure:

1. **Quick wins** -- build flags, missing indexes/caching, timeouts/pool limits, avoidable allocations/copies, sync I/O in hot paths, missing `await`/join, safer bounds checks, log noise, config limits. Low risk.
2. **Structural** -- bound concurrency, batch N+1, stream large payloads, change data structures/ownership, split hot paths, cache correctly, connection/worker pools, graceful shutdown, observability. Name each behavior change.
3. **Heavy** -- language/toolchain major upgrade, runtime/GC change, framework/ORM swap, architecture change, AOT/trimming, database migration. Separately approved.
   Each step: files touched, expected effect, how to verify, how to roll back.

### 5. Fix

Only approved items, in small groups. After each: build with production flags, run the test suite, and re-run the same benchmark/profile. A break must trace to one change. Do not mix a toolchain major upgrade with optimization edits. If a change alters ownership, concurrency, API/DB semantics or failure behavior, stop and ask.

### 6. Verify and wrap up

Re-measure the same workload and data: throughput and p50/p95/p99, CPU, RSS/heap, allocations/GC, I/O, error rate, build time and binary/image size. State plainly what could not be measured. End with deferred items and one suggested next step.

## Principles

- **C++23 is the published target.** C++26 is not an ISO-published standard yet; use it only experimentally.
- **RAII and value semantics first.** Ownership and lifetime bugs are performance bugs.
- **Count copies and allocations.** `reserve`, moves, `string_view` and `span` beat micro-tuning.
- **Concurrency is a design.** Threads, atomics and coroutines need ownership and shutdown rules.
- **Measure with sanitizers and a profiler.** A fast wrong answer is still wrong.

## Docs

- https://en.cppreference.com/w/cpp/23

• LICENSE 1 KB
• README.md 1 KB
• SKILL.md 5 KB
• assets/report-template.md 1 KB
• references/build-runtime.md 1 KB
• references/io-data.md 1 KB
• references/memory-concurrency.md 1 KB
• references/safety-quality.md 1 KB
• references/tooling.md 1 KB
• scripts/audit.py 9 KB