第1章：优化全景

从“优化不是项目最后一周”开始

optimization 的对象不是“能运行但随便写的代码”，而是 correct、可维护、已有明确需求的 C++ program。性能约束和 correctness 一样属于 product contract：frame 必须在 16.7 ms 内、request p99 小于 100 ms、embedded task 不超能耗/内存预算。若直到发布前才检查，这些约束往往已被 architecture 固化。

优化并不意味着每一行都手工调节。它意味着：在 design 时选择可扩展 algorithm/data ownership，在 implementation 时让 compiler 看得清，在 test 时保存 baseline，在 production 中监控真实 workload。后续章节会给出 measurement 细节；本章先建立策略空间和数量级意识。

Optimization Is Effective

性能并非不可控“黑盒”。算法从 quadratic 改为 near-linear、把每次 request 的 allocation 从千次降到十次、批量 I/O 减少 system calls，都能产生显著且解释得通的收益。关键是目标 metric 和 workload 可重复，改动前后 correctness 相同。

bool containsDuplicate(const std::vector<int>& values) {
    for (std::size_t i = 0; i < values.size(); ++i) {
        for (std::size_t j = i + 1; j < values.size(); ++j) {
            if (values[i] == values[j]) return true;
        }
    }
    return false;
}

这段代码在 large n 下应优先比较 sort+adjacent 或 hash set，而不是先修改内层 if。order-of-growth change 可以超过任何 instruction-level tweak；但小 n、memory limit、input distribution 仍可能改变最佳 choice，因此最终要测 representative range。

It Is OK to Optimize

“premature optimization is the root of all evil” 反对的是在不知道 bottleneck/requirements 时牺牲 clarity，不是禁止性能工程。用 linear algorithm 代替 quadratic、避免无意义复制、选择 release optimizer 都可以同时提高 clarity。真正危险的是 obscure trick 没有 benchmark、依赖 undefined behavior 或把 ownership 变成悬空 view。

A Nanosecond Here, a Nanosecond There

总成本可用粗模型 cost_per_operation × operation_count 先排序。一个 hash probe 少 5 ns，每秒执行 2 亿次就是约 1 CPU-second/s 的量级；一个 startup helper 快 5 ms 但每天运行一次，对 server capacity 几乎无影响。粗模型不是 benchmark 替代，而是决定先实验哪条 hypothesis。

struct CostEstimate {
    double nanoseconds_per_call;
    std::uint64_t calls_per_second;
};
 
double cpuSecondsPerSecond(CostEstimate estimate) {
    return estimate.nanoseconds_per_call *
           static_cast<double>(estimate.calls_per_second) / 1e9;
}

还要考虑 tail latency、cache/contention 和 energy：平均只省一点的改动，若消除 p99 allocator stall 可能价值更高；在 battery device 上，CPU-seconds reduction 也是 energy budget。所有估算都应在第 3 章转成 measured baseline。

C++ 优化策略组合

Use a Better Compiler, Use Your Compiler Better

先比较当前 toolchain 的 optimized build，而不是用 debug build 评判 language feature。检查 target CPU、inlining/LTO/PGO、sanitizer 与 release reproducibility。compiler 可以 constant-fold、vectorize、devirtualize，却不能安全猜测 undefined behavior、hidden alias 或 opaque module semantics。

double dot(std::span<const double> left,
           std::span<const double> right) {
    double result = 0.0;
    for (std::size_t i = 0; i < left.size(); ++i) {
        result += left[i] * right[i];
    }
    return result;
}

清晰 contiguous ranges、matching sizes 和 visible loop 比手写奇怪 pointer arithmetic 更容易优化。若 numeric semantics 允许 reassociation/vectorization，要把 accuracy contract 和 compiler flags 写进 experiment。

Use Better Algorithms and Better Libraries

algorithm 是最高杠杆之一；library 则把 tuned algorithm、SIMD、platform knowledge 和 correctness 集中复用。优先使用标准/成熟库表达 intent，但不要盲信任何 abstraction：检查 complexity、allocation、iterator category、exception 和 data layout 是否匹配 workload。

Reduce Memory Allocation and Copying

reserve/preallocate、move/value return、borrowed view、arena/batch 都可能减少 allocator 与 bytes moved。不能为了零 copy 返回 dangling reference，也不能把 unique ownership 变 shared ownership。第 4、6、13 章会分别从 strings、dynamic variables 和 memory manager 深挖。

Remove Computation and Use Better Data Structures

cache 与 precompute 用 memory/complexity 换 repeated work；batching 用 latency/queue 换 amortized cost。data structure 决定 lookup/update complexity 与 locality。选择必须同时覆盖 reads、writes、iteration、size distribution、stable references 和 memory ceiling。

Increase Concurrency and Optimize Memory Management

parallelism 不能修复低效 algorithm，反而增加 queue、lock、cache coherence 和 failure complexity。先优化 single-task work，再按 Amdahl limit 识别 parallel fraction。memory manager 优化则适合 allocation 确实是 hotspot、size/lifetime pattern 稳定的场景；arena/fixed block 的 policy 必须记录 alignment、thread safety、fragmentation 和 bulk teardown。

三步建立优化决策

第1章策略选择清单

1. 写出 correctness contract 与 target latency/throughput/memory/energy。
2. 用单次成本 × 执行次数估算候选 upper bound。
3. 先问能否删除 work、降低 complexity 或减少 traffic。
4. 比较 compiler/library 已有能力，避免维护重复低层实现。
5. allocation/copy 优化必须保留 ownership 与 exception safety。
6. data structure 用完整 read/write/iteration distribution 评估。
7. concurrency 先算 serial fraction、coordination 和 core budget。
8. 每个策略准备 baseline、A/B、correctness test 和 rollback。

小结

• optimization 是 software development 的性能约束管理，不是发布前临时活动
• optimization 在减少 work、traffic 或增长级别时有效，必须保持 correctness 可重复验证
• 有目标和证据的优化是合理工程；反对 premature tuning 不等于忽略性能预算
• nanosecond 价值由 execution count 放大，冷路径毫秒改进也可能无系统价值
• better compiler、algorithm 和 library 通常先于手工低层技巧
• allocation/copy、computation 和 data structure 决定大量 C++ workload 的核心成本
• concurrency 只有在 work 足够独立且 coordination 更小时才加速
• memory manager 是 pattern-specific 策略，需同时审计 lifetime、fragmentation 和 thread safety