总复习：从性能事故到证据闭环

从一次真实性能事故开始

假设一个C++事件评分服务升级后出现四个症状：吞吐下降20%，p99从目标范围外移，RSS峰值增长，8 threads只比1 thread快1.6倍。团队提出“换allocator”“改lock-free”“把transform扔GPU”三个方案，但目前没有证据说明任何一个是cause。

先预测问题属于哪层，然后冻结revision、compiler、flags、hardware和representative input。全书11章提供的不是11个互斥答案，而是从contract到execution的审计顺序。

第1-2章：先恢复接口和value契约

事件进入pipeline时，先画value、borrow、owner与failure边界。一次“减少copy”的改动若把owned string改成string_view，却让异步task晚于source lifetime，就不是优化而是correctness bug。lambda capture、std::function、optional/any和move也要按representation审计。

input owner -> parse value -> score task -> result owner
             borrow only inside synchronous parse
             async capture owns required state
failure: parse error | absent score | task exception

检查copy/move counters和allocation后，若std::function持有large closure而超出small buffer，可能产生allocation；但不能假设每次都如此。若plain auto从reference result复制大型value，也要从type deduction证明。第1-2章负责排除“程序已经不等价”与“语法隐藏cost”。

第3章：把症状变成实验

p99、throughput与RSS是不同performance properties。建立三个benchmarks：micro隔离score kernel，component包含queue与allocation，end-to-end覆盖parse到response。对A/B交错执行，报告distribution和uncertainty，并用sampling profile取得inclusive stacks。

baseline: throughput + median/p95/p99 + allocations + peak RSS
profile : CPU stacks + lock wait + cache/TLB + faults
compare : effect size + uncertainty + correctness oracle

若allocator占25% inclusive samples，应沿call stack回到producer：是container rehash、string temporary、shared_ptr control block还是arena缺失。profile指向“哪里”，不自动给出“为什么”。

第4-6章：先修数据形状和算法工作量

profile显示大量node traversal与full sort。第4章要求按access pattern比较vector/list、ordered/hash container与parallel arrays；第5章检查custom iterator category是否真实；第6章判断只需top-100是否应partial_sort而非全sort。

若records按node分散、hot loop只读score和id，可比较compact vector/SoA；若hash table在关键窗口rehash，reserve或不同policy可能移出spike；若iterator谎报random access，generic algorithm可能隐藏二次成本。每项修改都保留logical workload一致。

full sort large records
  -> compact {score,index}
  -> partial_sort top-k
  -> gather selected records
 
measure: comparisons | moved bytes | cache misses | allocations

复杂度选择与locality必须共同成立。n很小时full sort常数可能更好；large payload下index sort减少bytes；top-k接近n时partial方案优势消失。结论绑定n/k与record distribution。

第7-9章：追踪storage和推迟的工作

第7章将allocation拆为virtual pages、allocator storage、construction、ownership和release。若request objects共享lifetime，可实验arena；若短string占主导，先核实SSO；若shared ownership非必要，unique/value减少control block和atomic traffic。

第8章检查type traits与if constexpr是否选择预期fast path，同时监控template instantiation和binary。第9章检查string proxy是否安全借用、DistProxy是否真的减少sqrt，以及lazy conversion是否重复执行。

arena让allocate变成bump，却把memory保留到reset；lazy proxy减少temporary，却可能延长operand lifetime或重算；compile-time specialization消除runtime branch，却增加build与icache压力。只记录被消除的cost会产生虚假胜利。

第10章：证明共享状态与扩展上限

1到8 threads仅1.6倍可能来自serial fraction、mutex queue、atomic retry、false sharing、memory bandwidth或load imbalance。先画scaling curve，再分解wait、run queue、cache-to-cache和bandwidth。每个shared state都需mutex或atomic happens-before证明。

condition variable必须等待predicate并支持shutdown；thread pool要有backpressure；SPSC queue不能误用为MPMC。release/acquire publication只有在acquire读取对应release value时才发布ordinary payload。用TSan与stress发现执行问题，但语言级证明仍不可省。

降低contention通常先分区、local accumulate再reduce、batch updates或缩短critical section。lock-free是progress property，不是“没有mutex”标签；CAS风暴可能比blocking lock更差。

第11章：并行算法和GPU是最后的执行选择

score transform若elements独立、function足够重且output disjoint，可比较seq/par/par_unseq。count_if使用local reductions；stable copy_if使用flags、count、prefix sum和scatter；reduce允许重排，floating result需tolerance。

GPU方案必须测H2D、launch、kernel、D2H与queue wait。只有data能驻留device并连续执行多个kernels，或arithmetic intensity足够高时，kernel throughput更可能覆盖fixed overhead。

parallel policy是permission，不是保证；implementation可能串行。callable side effects、exception规则、grain和bandwidth都需核查。保留serial oracle，确保parallel/GPU结果在定义的ordering与numeric tolerance内等价。

一条可审计的修复路径

对该事故，证据最终可能显示：full sort large records与temporary strings制造40%工作，global result counter产生false sharing，GPU transfer大于kernel节省。合理修复是compact key+partial_sort、reserve/append或安全string proxy、per-worker counter后reduce；GPU方案被实验否决并记录。

最终报告不是“用了高级技术”，而是：p99/throughput/RSS effect与uncertainty；hotspot如何变化；正确性和sanitizer结果；适用input/hardware边界；失败方案及原因；regression benchmark。这样下一次回归可以从证据继续，而非重开猜测。

全书11章知识压缩

1. 第1章：zero-cost abstraction必须与value、ownership、error contract一起看。
2. 第2章：auto/lambda/move/optional/any改变type、capture和representation。
3. 第3章：复杂度给增长方向，实验与profile给目标场景证据。
4. 第4章：container和parallel arrays由memory properties与access pattern选择。
5. 第5章：iterator category是语义与复杂度承诺。
6. 第6章：algorithm、predicate、partial order与views表达最少有效工作。
7. 第7章：virtual page、storage、object lifetime、RAII与allocator分层。
8. 第8章：traits/constexpr/reflection把可证明事实前移，同时支付build成本。
9. 第9章：proxy/lazy只在能跳过、融合或减少materialization时获益。
10. 第10章：共享状态需要happens-before，scaling受contention和hardware限制。
11. 第11章：parallel STL/GPU要求可拆work、独立output和端到端收益。

小结

• 性能事故先恢复contract与correctness，再建立可归因measurement
• 数据结构、iterator和algorithm共同决定有效工作量与地址序列
• memory、compile-time和lazy optimization都在迁移代价，而非消灭所有代价
• concurrency需要happens-before和scaling evidence，lock-free不是默认终点
• Parallel STL与GPU只有在grain、data residence和merge成立时才加速
• 完成标准是四类门禁和可重现证据包，不是某个单点benchmark绿色