一、C++性能优化概述
为什么需要性能优化
说实话，我见过太多人把性能优化当成「锦上添花」的事。直到线上系统崩了，才后悔当初没多花点时间。
性能优化不是炫技。它解决的是实实在在的问题：
- 用户体验：用户等不了 3 秒。我做过一个图像处理库，优化前处理一张图要 2.8 秒，优化后降到 0.3 秒。用户反馈从「太慢了」变成了「秒开」。
- 成本控制：同样的业务，优化后服务器数量减半。省下来的钱，够养一个团队了。
- 系统稳定性：性能差的系统，在高并发下容易雪崩。你想想看，一个请求慢 100ms，1000 个请求就是 100 秒的累积延迟。
核心观点：性能优化是「投资」，不是「开销」。早优化，早受益。
性能优化的目标与原则
我刚开始做优化时，也犯过「为了优化而优化」的毛病。后来总结出三条原则，一直贴在工位上：
- 先测量，后优化——没有数据支撑的优化都是瞎猜。我曾经凭感觉改了一段代码，结果性能反而下降了 20%。
- 二八定律——80% 的性能瓶颈集中在 20% 的代码里。别到处撒网，先找到热点。
- 可读性不牺牲——优化后的代码如果没人能看懂，那这个优化就是失败的。团队协作比单点性能更重要。
说白了，性能优化的目标就三个字：快、稳、省。
| 维度 | 目标 | 我的经验 |
|---|---|---|
| 快 | 降低延迟，提高吞吐 | 优先优化热点路径，别在冷代码上浪费时间 |
| 稳 | 性能波动小，可预测 | 避免动态分配、虚函数等不可控因素 |
| 省 | 减少 CPU、内存、带宽消耗 | 能用栈就不用堆，能复用就不新建 |
性能优化的常见误区
嗯，这里我要重点说说。我踩过的坑，希望你别再踩一遍。
误区一：过早优化
「过早优化是万恶之源」——这话没错，但很多人理解偏了。不是不优化，而是不要在没搞清楚瓶颈在哪之前就动手。我曾经花了一周优化一个排序算法，结果发现瓶颈在 I/O 上。白干了。
误区二：迷信「高级特性」
有人觉得用了 C++17、C++20 就代表性能好。其实不然。std::optional 很方便，但如果你在热循环里用它，性能可能还不如一个简单的 bool 判断。我见过一个项目，大量使用 std::variant，结果性能比手写 union 差了 3 倍。
误区三：忽略编译器优化
很多人写代码时完全不考虑编译器会怎么优化。举个例子：
// 糟糕的写法
for (int i = 0; i < vec.size(); ++i) {
if (vec[i] > 0) do_something(vec[i]);
}
// 更好的写法
for (auto& v : vec) {
if (v > 0) do_something(v);
}第二种写法不仅可读性更好，而且更容易被编译器优化。我建议你写代码时，多想想「编译器会怎么处理这段代码」。
避坑指南：我曾经接手过一个项目，代码里到处都是 std::shared_ptr。问为什么用，答曰「怕内存泄漏」。结果性能惨不忍睹。后来我改成 unique_ptr + 裸指针传递，性能提升了 40%。记住：智能指针不是银弹，用之前想清楚。
知识体系总览
下面这张图，是我对性能优化知识体系的总结。你可以把它当作一张地图，后续章节都会围绕这些核心点展开。
这张图展示了性能优化的三大支柱：测量、内存、算法。三者缺一不可。我个人的习惯是：先花 30% 的时间做测量和定位，再花 50% 的时间做优化，最后 20% 的时间做验证和回归测试。
一个小建议：刚开始学性能优化时，别贪多。先把「测量」这一块吃透。你连瓶颈在哪都不知道，优化个啥？