CPP-Summit 2025 的学习笔记写到了第四篇。我注意到很多刚入门 C/C 的朋友是从“VSCode 配置 C/C 环境”“跑通第一个 C/C 程序”开始的这些热搜词背后是一条很典型的学习路径环境配好了、代码能跑了接下来自然会问一句——“我写的程序到底快不快如果不快卡在哪” 这一篇笔记就是围绕高性能 C/C 系统性能优化这个主题把这次峰会上我收获最大的几个 session 内容结合自己会后复现和平时调优的经验从理论到实践完整整理一遍。适合已经能写 C/C 程序、但还没系统接触过性能分析与优化的读者如果你已经在做服务端、游戏、嵌入式等方向这篇文章也可以帮你把零散的经验串成框架。1. 一个最反直觉的结论性能是系统属性不是代码属性1.1 会调代码不等于会优化峰会第一天上午有位讲者开场就抛出了这句话性能问题几乎从来不是某个函数本身的问题而是这个函数和整个系统如何交互的问题。这句话我太有感触了。以前收到性能反馈第一反应就是打开热点函数盯着循环、表达式、算法复杂度调半天。结果往往是单个函数优化了整体延迟一点没降。原因很简单——那个函数根本就不是真正卡住系统的环节它只是刚好被采样到了而已。更典型的例子是两个团队各自把自己模块优化了 50% 和 40%听起来成果很大但端到端整体只快了不到 5%。为什么因为链路里最贵的一次等待发生在串行环节网络发送前的序列化、磁盘调度、跨进程通信排队。你优化再多的并行部分最终也要被这段串行时间卡住。这就是 Amdahl 定律的现场教学版系统加速比 1 / ((1 - P) P / N)P 是可并行部分占比N 是并行度。只要串行部分是 5%就算你把并行部分优化成无限快整体最多也就快 20 倍左右。反过来如果把那个 5% 压到 1%收益可能比砸一堆 CPU 核数更明显。1.2 从“调快一段代码”到“消除系统性浪费”所以我在这次学习里最大的转变是从“怎么把这段代码写得快”变成“整条路径上哪些时间是被浪费掉的”。什么叫系统性浪费就是那些看起来每个环节都很小、但叠加起来非常可怕的隐性开销数据在主存和 CPU 缓存之间反复搬运线程在锁上排队、睡眠、唤醒、切换一次小数据包触发一次系统调用日志、序列化、分配器里隐藏的锁竞争。这些浪费不会直接出现在某个函数的热点里但它们的总和往往就是那个“慢了 10 倍”的真相。一个可落地的做法是在优化前先画一条请求路径图。从数据进入进程开始经过哪些函数、哪些数据结构、哪些系统调用、哪些锁标注每一步的耗时占比用 profiler 采样。你会发现真正值得动手的地方跟你直觉以为的地方经常完全不重合。这一步在整个性能优化流程里价值被严重低估但 CPP-Summit 上几位资深讲师都把它列为第一步。2. 编译器不是魔法但用好编译选项能白拿两位数收益2.1 LTO 与 PGO现场实测的收益编译器是性能优化里最“便宜”的杠杆——你不需要改任何代码只要正确使用编译选项就可能拿到 8% 到 15% 的收益。这次峰会上有位编译器方向的讲者展示了一个中间件项目的数据开启LTOLink-Time Optimization链接时优化后跨编译单元的内联、常量传播、死代码消除全面生效性能提升约 8%~12%。再叠加PGOProfile-Guided Optimization基于性能剖析的优化用真实负载收集分支和调用频率让编译器在热点路径上做激进优化整体再提升 5%~8%。两者叠加总共接近 20%而且业务代码一行没动。PGO 的具体做法是两阶段编译# 第一阶段生成带 profile 信息的版本 g -O3 -fprofile-generate -o app_profile main.cpp worker.cpp # 用代表性负载跑一遍产出 .gcda 数据 # 第二阶段使用 profile 数据优化编译 g -O3 -fprofile-use -o app_final main.cpp worker.cpp注意一个关键细节训练负载必须贴近真实场景。如果你拿读写均衡的测试数据去训练但线上是读多写少PGO 反而可能让编译器把分支优化到错误方向性能还不如不开。2.2 -marchnative 的收益与陷阱会议上有讲者调侃很多人开了 -O3 就觉得自己优化完了其实漏掉了一个大头——指令集选择。默认的 x86-64 基线指令集只保证最保守的功能。如果你用较新 CPU 跑项目但没有指定-marchnative编译器就永远不会生成 AVX2、AVX-512 等 SIMD 指令自动向量化能力大打折扣。实测中一个密集数值计算模块在支持 AVX-512 的 CPU 上-O3 -marchnative比-O3默认基线快 30%~60% 都是正常的。但这里有两个必须避开的坑踩坑一用-marchnative编译出的二进制如果拿到不带对应指令集的老 CPU 上运行可能在执行到 AVX-512 指令时直接崩溃非法指令异常。修复方式是部署时确认 CPU 型号统一或者用-marchx86-64-v3这类较新的通用基线在可移植性和性能之间取折中。踩坑二-fno-omit-frame-pointer这个选项经常被忽视。它会让二进制稍微变大一点点但能让perf采集到的调用栈变得可用。否则你会看到一堆问号函数火焰图直接废掉。性能分析环境建议统一开启。我自己的 CMake 工程里性能相关配置长这样set(CMAKE_CXX_FLAGS_RELEASE -O3 -marchx86-64-v3 -flto -fno-omit-frame-pointer)如果只在本机跑 Demo可以换成-marchnative如果要做分发部署就用-marchx86-64-v3并配合 CI 机器统一。2.3 会读汇编才算是真正入门的性能优化这个观点来自一场非常硬核的 session。讲者说如果你想知道编译器到底把你的代码优化成了什么样不要猜直接看汇编。工具方面本地用objdump -d日常快速验证推荐在 Compiler Explorergodbolt.org里直接看不同编译选项下的汇编差异。重点是观察几点热点循环是否被向量化出现vaddpd、vmulps这类 SIMD 指令说明向量化成功分支是否被预判有无大量jmp、分支跳转是否被优化成条件选择指令cmov变量是否被放进寄存器如果看到大量mov进出内存说明局部性不好或者优化不彻底函数是否被内联判断call指令是不是指向一堆小函数。我自己会后在项目里试了一次一个字符串处理函数开启-O3 -marchnative后能清楚看到编译器用 AVX2 一次处理 32 字节速度是原来的好几倍。不看汇编你可能永远不知道还有这个优化空间。不过也要泼一盆冷水编译器优化永远替代不了算法复杂度优化。一个错误的算法比如 O(n²) 的循环开再狠的编译选项也追不上 O(n log n) 的正确实现。所以先保证数据结构和算法正确再用编译器优化做锦上添花。3. 真正的瓶颈在内存子系统缓存、局部性、分配器3.1 CPU 的“存储金字塔”决定了性能量级这次峰会上记忆最深刻的一个图表是 CPU 存储层级延迟对比。很多人以为内存很快其实在 CPU 眼中主存慢得令人发指。存储层级大致延迟类比L1 Cache约 1ns自己桌面上的笔记本L2 Cache约 3~5ns工位旁边的文件柜L3 Cache约 10~20ns楼层公共资料室主内存约 50~100ns开车去档案馆取一份文件CPU 一秒钟能跑几十亿次指令但每次访问主存都要等几十纳秒。如果你的程序频繁 cache missCPU 大部分时间不是在计算而是在等数据。这就是为什么“看起来算法复杂度一样实际运行时间差十倍”的根本原因。一个最经典的验证实验是矩阵遍历顺序。同样一个 4096×4096 的 double 二维数组#define N 4096 static double a[N][N]; // 行优先遍历好连续访问同一行充分利用 cache line double sum 0; for (int i 0; i N; i) for (int j 0; j N; j) sum a[i][j]; // 列优先遍历差每次跳一行等于每访问一个元素就要重新加载缓存行并换页 double sum2 0; for (int j 0; j N; j) for (int i 0; i N; i) sum2 a[i][j];列优先版本慢 20 倍以上不是编译器的问题是每次访问a[i][j]都跳到了完全不同的内存页。代码没有变变量布局变了性能就完全不同。3.2 数据结构就是性能设计AoS 与 SoA顺着局部性往下走另一个高频话题是AoSArray of Structures与 SoAStructure of Arrays的取舍。以游戏粒子系统为例一个粒子有位置、速度、颜色、存活时间四个字段。用 AoS 写法是把每个粒子封装成一个对象再放进数组struct Particle { float x, y; // 位置 float vx, vy; // 速度 uint8_t r, g, b; // 颜色 float life; }; std::vectorParticle particles; // AoS但如果某个阶段只需要更新所有粒子的位置和速度AoS 布局会让 cache line 里混入大量当前用不到的字段颜色、生命期白白浪费带宽。SoA 布局则是把每种字段单独放一个数组struct ParticlesSoA { std::vectorfloat x, y; // 所有粒子的 x、y std::vectorfloat vx, vy; // 所有粒子的速度 std::vectoruint8_t color; // 颜色 std::vectorfloat life; // 生命期 };这样在遍历更新位置时内存访问是连续线性的而且更容易自动向量化。现场展示的案例里粒子系统从 AoS 改成 SoA 后单纯的位置更新阶段快了 3 倍。代价是代码可读性变差、单粒子访问逻辑变麻烦。当某个阶段只访问对象的少数字段并且数据规模很大时SoA 基本是稳赢的。但这不是万能方案。如果业务逻辑频繁访问一个对象的全部字段AoS 反而更友好。判断标准很简单看你的热点循环到底需要哪些字段让 cache line 装的全是热点需要的东西。3.3 malloc 不是默认答案分配器选型也是性能优化这一部分是我自己平时容易忽略的也是这次会议上被专门提出来讲的重点之一。默认的malloc在多线程高并发下有一个隐藏问题为了线程安全它会维护多个 arena但在分配释放非常频繁的场景下锁竞争和元数据开销仍然明显。64 线程同时做大量小对象分配时malloc 消耗的时间可能占整体运行时间的 10%~20%而这些时间完全不会出现在业务函数的调用栈热点里。替换方案主要是tcmalloc和jemalloc。它们通过“线程本地缓存”大幅减少跨线程的锁交互每个线程优先从自己的本地池取内存本地池不够了才去全局池申请。实测在纯多线程分配压力测试中换分配器后整体吞吐可以提升 2~5 倍业务场景里如果分配密集提升 20%~40% 也不夸张。不过我踩过一次坑不是所有场景换分配器都是正收益。某个低频分配、但持有内存时间巨长的服务换了 jemalloc 后内存占用反而上升了因为线程本地缓存会滞留空闲块。所以衡量方式必须用 profiling先用perf或heaptrack确认分配器确实在消耗可观的时间再动手换。如果是自研固定大小的对象池比如网络连接池、游戏实体池还真不一定需要外部分配器。用std::array预分配 空闲链表能完全避免 malloc 的元数据开销同时天然具备 vector 的缓存友好性。这一招在 CPP-Summit 的网络框架 session 里被反复提及。4. 并发优化锁、伪共享、线程模型三个现场复现都值得自己跑一遍4.1 锁竞争的本质是排队不是锁本身并发优化是系统性能优化里最容易写出行之有效技巧的部分也是最容易拍脑袋的部分。很多人觉得“锁慢”是因为加锁这个操作本身有成本。其实互斥锁在无竞争时的一次加锁解锁只有几十纳秒真正常态几百倍开销的是锁竞争引发的线程睡眠、唤醒、上下文切换。一个典型的场景8 核机器开了 16 个线程每个线程处理任务时都要抢同一把锁。核心观察是线程 A 持有锁处理任务线程 B 抢锁失败进入睡眠线程 A 释放锁并唤醒线程 B线程 B 被唤醒后要重跑调度器、恢复上下文此时 L1/L2 缓存里全是其他线程留下的数据缓存命中率骤降。这一整套过程单次看起来只有微秒级但在高并发下会像高速公路的收费站一样形成排队效应。你会看到 CPU 用量不低但业务吞吐就是上不去——大量 CPU 时间花在锁的排队和调度上。优化的优先级应该是能不共享就不共享比如 thread-local 变量缩小临界区只在最短执行路径上加锁换更合适的同步原语原子变量、读写锁、无锁队列最后才考虑锁的底层实现优化。4.2 false sharing一个经典且隐蔽的性能杀手这个知识点几乎每次 CPP 技术峰会都会出现因为它是“多线程下看起来毫无道理地慢”的头号元凶。问题背景两个线程分别操作两个不同的原子变量听起来互不干扰但这两个变量如果恰好落在同一个 64 字节 cache line 里情况就变了。CPU 的缓存一致性协议要求当一个核心修改了某个 cache line 上的数据时其他核心持有该 cache line 的副本必须作废。于是两个本该各写各的线程会因为共享 cache line 而不断互相“踢下线”形成无意义的同步流量。现场 demo 复现过这个场景两个线程各自对一个std::atomicuint64_t做累加结果共享同一个缓存行时吞吐下降了一个数量级。修复方式非常简单#include atomic #include cstdint // 错误两个 Counter 对象很可能落在同一 cache line struct Counter { std::atomicuint64_t value{0}; }; // 修复按 cache line 大小对齐保证每个对象独占缓存行 struct alignas(64) CounterAligned { std::atomicuint64_t value{0}; }; CounterAligned counters[2]; // 线程 0 操作 counters[0] // 线程 1 操作 counters[1]alignas(64)在这里的意义是让每个CounterAligned对象占用独立缓存行。如果你的 C17 编译器支持std::hardware_destructive_interference_size可以用它代替硬编码的 64不过很多环境需要手动定义宏用alignas(64)反而是最保险的通用做法。这个坑特别隐蔽的点在于它不是逻辑错误不开启任何 sanitizer 都查不出来它只在特定机器、特定内存布局、特定线程数量下触发。排查手段也很依赖 profiler 的缓存事件统计比如perf stat -e cache-misses, cycles对比不同版本。所以我在项目里看到“多线程版本反而比单线程慢了一半”的第一反应现在就是检查 cache line 是否被打崩。4.3 线程模型多开线程不等于更快“我用多线程重写了每核一个线程为什么不快反慢”这是 session 问答环节出现频率最高的问题。原因有两层。第一层是前面说的线程多了之后锁竞争、缓存在核心之间横跳、调度开销都会上涨。第二层是线程创建与销毁本身是昂贵的每次创建线程要分配栈空间、建立内核调度实体销毁时还要回收。如果任务生命周期很短创建线程的成本可能比任务执行本身还高。正确思路是固定数量线程池线程数一般不超过硬件线程数超线程可以适当放宽不用管任务本身的生命周期IO 密集型场景考虑协程C20 有了coroutine标准支持再加上无栈协程方案可以让海量 IO 任务共用一个线程避免海量线程的调度开销无锁队列适合单生产者单消费者boost::lockfree::spsc_queue或者自研 MPSC 队列在非泛化场景下效果显著但别为了炫技而用。会议上总结的一句话我记下来了能用线程池解决的问题别直接用裸线程能用协程解决的问题别硬上更多线程。5. 没有度量一切都是猜测perf 和火焰图的一线排查实操5.1 先压测再优化否则你连问题在哪都不知道这一节我想把重心完全放在实践上。因为性能优化领域最大的错误不是优化错了而是直接动手优化连 baseline 都没有。我自己的标准流程分四步压测用wrk、ab或自研压测脚本确定当前吞吐、P50/P95/P99 延迟记录下来当作基线采样用perf等 profiler 采集 CPU 热点、锁等待、缓存行为假设根据采样结果列出候选瓶颈按“影响面 × 修复成本”排序验证每改一处重新压测对比 baseline决定保留还是回滚。这四步的纪律非常重要。我见过太多人一上来就把unordered_map换成更花哨的数据结构结果瓶颈根本不在查找本身压测数据证明性能纹丝不动——浪费了时间还增加代码复杂度。5.2 perf 工具链速览从 top 到 recordLinux 上首选工具就是perf它基于内核的硬件性能计数器开销极低适合线上的第一轮抽丝。最基本的三个命令# 1. 实时观察进程内最耗 CPU 的函数 perf top -p $(pgrep your_app) # 2. 统计周期内整体的缓存命中、IPC、上下文切换概况 perf stat -e task-clock,cycles,instructions,cache-misses ./your_app # 3. 记录完整调用栈用于事后生成火焰图 perf record -F 99 -g -- ./your_app perf report --stdio-F 99的含义是每秒采样 99 次这是 Brendan Gregg 经常推荐的频率既能得到足够采样点又避免因采样频率过高反过来影响被测程序。-g表示记录调用栈。perf report输出里Samples列的占比就是该函数在采样周期内的 CPU 时间占比。切记不要只看函数名还要看它的调用路径caller chain——同一个函数可能是被完全不同的两层路径调用的。5.3 火焰图读法别被入口函数骗了火焰图是性能分析最直观的呈现形式生成命令也不复杂git clone https://github.com/brendangregg/FlameGraph perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl flame.svg读火焰图有三个我特别想提醒的误区看宽度不看高度x 轴是采样占比所以“最宽”的那层函数才是真正吃 CPU 的主体。很多时候入口函数最顶层看起来巨大但真正热的是它调用链路深处某个叶子函数平顶栈是最佳目标如果一块区域呈现宽而扁的特征说明热点就在那一层自身代码里业务逻辑吃掉了大量 CPU这是最容易优化的地方考虑算法、SIMD、缓存布局不要盯着“看起来应该慢”的函数真正快的路径压根不会出现在火焰图的宽条区域里出现在宽条里的往往是你没想到的地方。补充几个适合不同场景的分析工具表格汇总如下工具适用场景备注perfCPU 热点、缓存事件、调用栈最有通用性先学它valgrind --toolcachegrind模拟缓存命中、分支预测适合离线分析小规模程序heaptrack/valgrind --toolmassif内存分配次数与内存堆积定位分配器瓶颈的大杀器Tracy/Perfetto可视化帧/任务级时间线适合客户端、游戏引擎的帧耗时分析gdb或strace挂死、系统调用异常排查问题用不是测性能用的6. 两个生产案例复盘系统调用批量化和缓存友好改造6.1 案例 A网络包处理路径上的系统调用消除我在峰会上记下的第一个案例是一个网络代理模块的性能问题。现象很明确单核吞吐上不去CPU 用量却不低。perf record之后发现样本里有相当大比例的耗时集中在recvfrom和sendto两个系统调用上。问题不仅仅是被调用的次数多而是每次系统调用都伴随用户态/内核态切换、寄存器上下文保存恢复、页表和指令缓存的干扰。高频系统调用会让流水线反复被“切断”。修复方案很经典把单包收发改成批量收发。// 优化前一个包一次系统调用 for (int i 0; i batch; i) { recvfrom(fd, pkt, len, ...); process(pkt); sendto(fd, out, len, ...); } // 优化后批量收、批量发大幅减少系统调用次数 recvmmsg(fd, msgvec, batch, MSG_WAITFORONE, NULL); for (int i 0; i batch; i) { process(msgvec[i].msg_hdr); } sendmmsg(fd, msgvec, batch, 0);现场给出的实测数据是系统调用次数下降了接近一个数量级视包大小不同从几十倍到几倍不等整体吞吐提升约 25%~30%。注意它的收益不在单个系统调用变得更快而是把整个处理流程从“频繁被打断”变成“连续工作”。这个案例给我的通用启发是如果你的热点栈里出现大量系统调用底层的函数如 syscall、entry_SYSCALL_64优先考虑减少调用次数而不是纠结系统调用本身的实现。常见的方案还有用户态缓存、合并小包、用io_uring做异步批量提交等。6.2 案例 B批量任务尾延迟的缓存友好改造第二个案例来自一个批量任务执行系统。需求是处理大量短任务每个任务包含一个 ID、若干字段、一个处理状态。最开始实现是每个任务一个对象塞进std::unordered_mapint, Task处理时按 ID 查找更新。现象是吞吐尚可但P95 延迟非常高而且任务量一上来P95 增长比 P50 快得多。排查后发现核心问题不是 unordered_map 本身的查找复杂度而是它的内存布局极度分散每个 Task 对象在堆上各自分配桶数组和节点链表又把数据打散到不同内存页。处理任务时CPU 每访问一个新任务几乎都在 cache miss还在分配新节点时触发了 malloc 的元数据开销。修复方案是把任务存储改成连续数组 紧凑索引// 优化后任务本体用连续 vector 存储 struct Task { uint64_t id; uint8_t status; // ... 其他字段 }; std::vectorTask tasks; // 连续内存顺序遍历时天然缓存友好 std::vectoruint32_t index; // 按某种顺序存储任务下标由于任务处理路径主要是按批次顺序遍历这个改动让 P95 延迟直接降了约 4 倍从 8ms 降到 2ms 左右。复杂度没变但内存局部性好了一个数量级。这个案例特别适合跟第 3 节的“数据结构就是性能设计”呼应。当你的热点循环是顺序遍历大量对象时连续数组永远比散列容器友好只有当“随机查找”才是主路径时哈希表的 O(1) 才有意义——而即便如此也建议用开放寻址法robin-hood hashing或flat_hash_map保持缓存局部性尽量不要用链表式实现。6.3 两个案例的共通逻辑与我的个人体会这两个案例表面上毫无关系一个消灭系统调用一个改造内存布局但底层逻辑一致性能优化的本质是消除浪费——减少等待、减少搬运、减少同步。网络代理案例减少的是“等待内核切换”的浪费任务系统案例减少的是“等待数据从主存搬进缓存”的浪费前面的锁优化、分配器优化减少的是“等待其他线程”和“等待分配器元数据”的浪费。如果非要用一句话概括这次 CPP-Summit 学习笔记第四篇的核心系统性能优化从来不是某个单一技巧的堆砌而是一套“度量—假设—验证”的工程方法加上对 CPU、内存、并发三种资源的系统性理解。我在会后的实际项目里已经按这套流程完整走了一遍效果比我以前凭感觉优化靠谱太多。如果你也是刚从配好环境、跑通 C/C 程序的阶段走出来我建议你现在就装上perf拿自己的项目跑一次perf record -F 99 -g看着火焰图你会发现一个全新的世界。 
长河君 · 2026/10/10 16:25:30 · 阅读 1.2k C/C++高性能系统优化实战：从Perf火焰图到缓存与并发调优
CPP-Summit 2025 的学习笔记写到了第四篇。我注意到很多刚入门 C/C 的朋友是从“VSCode 配置 C/C 环境”“跑通第一个 C/C 程序”开始的这些热搜词背后是一条很典型的学习路径环境配好了、代码能跑了接下来自然会问一句——“我写的程序到底快不快如果不快卡在哪” 这一篇笔记就是围绕高性能 C/C 系统性能优化这个主题把这次峰会上我收获最大的几个 session 内容结合自己会后复现和平时调优的经验从理论到实践完整整理一遍。适合已经能写 C/C 程序、但还没系统接触过性能分析与优化的读者如果你已经在做服务端、游戏、嵌入式等方向这篇文章也可以帮你把零散的经验串成框架。1. 一个最反直觉的结论性能是系统属性不是代码属性1.1 会调代码不等于会优化峰会第一天上午有位讲者开场就抛出了这句话性能问题几乎从来不是某个函数本身的问题而是这个函数和整个系统如何交互的问题。这句话我太有感触了。以前收到性能反馈第一反应就是打开热点函数盯着循环、表达式、算法复杂度调半天。结果往往是单个函数优化了整体延迟一点没降。原因很简单——那个函数根本就不是真正卡住系统的环节它只是刚好被采样到了而已。更典型的例子是两个团队各自把自己模块优化了 50% 和 40%听起来成果很大但端到端整体只快了不到 5%。为什么因为链路里最贵的一次等待发生在串行环节网络发送前的序列化、磁盘调度、跨进程通信排队。你优化再多的并行部分最终也要被这段串行时间卡住。这就是 Amdahl 定律的现场教学版系统加速比 1 / ((1 - P) P / N)P 是可并行部分占比N 是并行度。只要串行部分是 5%就算你把并行部分优化成无限快整体最多也就快 20 倍左右。反过来如果把那个 5% 压到 1%收益可能比砸一堆 CPU 核数更明显。1.2 从“调快一段代码”到“消除系统性浪费”所以我在这次学习里最大的转变是从“怎么把这段代码写得快”变成“整条路径上哪些时间是被浪费掉的”。什么叫系统性浪费就是那些看起来每个环节都很小、但叠加起来非常可怕的隐性开销数据在主存和 CPU 缓存之间反复搬运线程在锁上排队、睡眠、唤醒、切换一次小数据包触发一次系统调用日志、序列化、分配器里隐藏的锁竞争。这些浪费不会直接出现在某个函数的热点里但它们的总和往往就是那个“慢了 10 倍”的真相。一个可落地的做法是在优化前先画一条请求路径图。从数据进入进程开始经过哪些函数、哪些数据结构、哪些系统调用、哪些锁标注每一步的耗时占比用 profiler 采样。你会发现真正值得动手的地方跟你直觉以为的地方经常完全不重合。这一步在整个性能优化流程里价值被严重低估但 CPP-Summit 上几位资深讲师都把它列为第一步。2. 编译器不是魔法但用好编译选项能白拿两位数收益2.1 LTO 与 PGO现场实测的收益编译器是性能优化里最“便宜”的杠杆——你不需要改任何代码只要正确使用编译选项就可能拿到 8% 到 15% 的收益。这次峰会上有位编译器方向的讲者展示了一个中间件项目的数据开启LTOLink-Time Optimization链接时优化后跨编译单元的内联、常量传播、死代码消除全面生效性能提升约 8%~12%。再叠加PGOProfile-Guided Optimization基于性能剖析的优化用真实负载收集分支和调用频率让编译器在热点路径上做激进优化整体再提升 5%~8%。两者叠加总共接近 20%而且业务代码一行没动。PGO 的具体做法是两阶段编译# 第一阶段生成带 profile 信息的版本 g -O3 -fprofile-generate -o app_profile main.cpp worker.cpp # 用代表性负载跑一遍产出 .gcda 数据 # 第二阶段使用 profile 数据优化编译 g -O3 -fprofile-use -o app_final main.cpp worker.cpp注意一个关键细节训练负载必须贴近真实场景。如果你拿读写均衡的测试数据去训练但线上是读多写少PGO 反而可能让编译器把分支优化到错误方向性能还不如不开。2.2 -marchnative 的收益与陷阱会议上有讲者调侃很多人开了 -O3 就觉得自己优化完了其实漏掉了一个大头——指令集选择。默认的 x86-64 基线指令集只保证最保守的功能。如果你用较新 CPU 跑项目但没有指定-marchnative编译器就永远不会生成 AVX2、AVX-512 等 SIMD 指令自动向量化能力大打折扣。实测中一个密集数值计算模块在支持 AVX-512 的 CPU 上-O3 -marchnative比-O3默认基线快 30%~60% 都是正常的。但这里有两个必须避开的坑踩坑一用-marchnative编译出的二进制如果拿到不带对应指令集的老 CPU 上运行可能在执行到 AVX-512 指令时直接崩溃非法指令异常。修复方式是部署时确认 CPU 型号统一或者用-marchx86-64-v3这类较新的通用基线在可移植性和性能之间取折中。踩坑二-fno-omit-frame-pointer这个选项经常被忽视。它会让二进制稍微变大一点点但能让perf采集到的调用栈变得可用。否则你会看到一堆问号函数火焰图直接废掉。性能分析环境建议统一开启。我自己的 CMake 工程里性能相关配置长这样set(CMAKE_CXX_FLAGS_RELEASE -O3 -marchx86-64-v3 -flto -fno-omit-frame-pointer)如果只在本机跑 Demo可以换成-marchnative如果要做分发部署就用-marchx86-64-v3并配合 CI 机器统一。2.3 会读汇编才算是真正入门的性能优化这个观点来自一场非常硬核的 session。讲者说如果你想知道编译器到底把你的代码优化成了什么样不要猜直接看汇编。工具方面本地用objdump -d日常快速验证推荐在 Compiler Explorergodbolt.org里直接看不同编译选项下的汇编差异。重点是观察几点热点循环是否被向量化出现vaddpd、vmulps这类 SIMD 指令说明向量化成功分支是否被预判有无大量jmp、分支跳转是否被优化成条件选择指令cmov变量是否被放进寄存器如果看到大量mov进出内存说明局部性不好或者优化不彻底函数是否被内联判断call指令是不是指向一堆小函数。我自己会后在项目里试了一次一个字符串处理函数开启-O3 -marchnative后能清楚看到编译器用 AVX2 一次处理 32 字节速度是原来的好几倍。不看汇编你可能永远不知道还有这个优化空间。不过也要泼一盆冷水编译器优化永远替代不了算法复杂度优化。一个错误的算法比如 O(n²) 的循环开再狠的编译选项也追不上 O(n log n) 的正确实现。所以先保证数据结构和算法正确再用编译器优化做锦上添花。3. 真正的瓶颈在内存子系统缓存、局部性、分配器3.1 CPU 的“存储金字塔”决定了性能量级这次峰会上记忆最深刻的一个图表是 CPU 存储层级延迟对比。很多人以为内存很快其实在 CPU 眼中主存慢得令人发指。存储层级大致延迟类比L1 Cache约 1ns自己桌面上的笔记本L2 Cache约 3~5ns工位旁边的文件柜L3 Cache约 10~20ns楼层公共资料室主内存约 50~100ns开车去档案馆取一份文件CPU 一秒钟能跑几十亿次指令但每次访问主存都要等几十纳秒。如果你的程序频繁 cache missCPU 大部分时间不是在计算而是在等数据。这就是为什么“看起来算法复杂度一样实际运行时间差十倍”的根本原因。一个最经典的验证实验是矩阵遍历顺序。同样一个 4096×4096 的 double 二维数组#define N 4096 static double a[N][N]; // 行优先遍历好连续访问同一行充分利用 cache line double sum 0; for (int i 0; i N; i) for (int j 0; j N; j) sum a[i][j]; // 列优先遍历差每次跳一行等于每访问一个元素就要重新加载缓存行并换页 double sum2 0; for (int j 0; j N; j) for (int i 0; i N; i) sum2 a[i][j];列优先版本慢 20 倍以上不是编译器的问题是每次访问a[i][j]都跳到了完全不同的内存页。代码没有变变量布局变了性能就完全不同。3.2 数据结构就是性能设计AoS 与 SoA顺着局部性往下走另一个高频话题是AoSArray of Structures与 SoAStructure of Arrays的取舍。以游戏粒子系统为例一个粒子有位置、速度、颜色、存活时间四个字段。用 AoS 写法是把每个粒子封装成一个对象再放进数组struct Particle { float x, y; // 位置 float vx, vy; // 速度 uint8_t r, g, b; // 颜色 float life; }; std::vectorParticle particles; // AoS但如果某个阶段只需要更新所有粒子的位置和速度AoS 布局会让 cache line 里混入大量当前用不到的字段颜色、生命期白白浪费带宽。SoA 布局则是把每种字段单独放一个数组struct ParticlesSoA { std::vectorfloat x, y; // 所有粒子的 x、y std::vectorfloat vx, vy; // 所有粒子的速度 std::vectoruint8_t color; // 颜色 std::vectorfloat life; // 生命期 };这样在遍历更新位置时内存访问是连续线性的而且更容易自动向量化。现场展示的案例里粒子系统从 AoS 改成 SoA 后单纯的位置更新阶段快了 3 倍。代价是代码可读性变差、单粒子访问逻辑变麻烦。当某个阶段只访问对象的少数字段并且数据规模很大时SoA 基本是稳赢的。但这不是万能方案。如果业务逻辑频繁访问一个对象的全部字段AoS 反而更友好。判断标准很简单看你的热点循环到底需要哪些字段让 cache line 装的全是热点需要的东西。3.3 malloc 不是默认答案分配器选型也是性能优化这一部分是我自己平时容易忽略的也是这次会议上被专门提出来讲的重点之一。默认的malloc在多线程高并发下有一个隐藏问题为了线程安全它会维护多个 arena但在分配释放非常频繁的场景下锁竞争和元数据开销仍然明显。64 线程同时做大量小对象分配时malloc 消耗的时间可能占整体运行时间的 10%~20%而这些时间完全不会出现在业务函数的调用栈热点里。替换方案主要是tcmalloc和jemalloc。它们通过“线程本地缓存”大幅减少跨线程的锁交互每个线程优先从自己的本地池取内存本地池不够了才去全局池申请。实测在纯多线程分配压力测试中换分配器后整体吞吐可以提升 2~5 倍业务场景里如果分配密集提升 20%~40% 也不夸张。不过我踩过一次坑不是所有场景换分配器都是正收益。某个低频分配、但持有内存时间巨长的服务换了 jemalloc 后内存占用反而上升了因为线程本地缓存会滞留空闲块。所以衡量方式必须用 profiling先用perf或heaptrack确认分配器确实在消耗可观的时间再动手换。如果是自研固定大小的对象池比如网络连接池、游戏实体池还真不一定需要外部分配器。用std::array预分配 空闲链表能完全避免 malloc 的元数据开销同时天然具备 vector 的缓存友好性。这一招在 CPP-Summit 的网络框架 session 里被反复提及。4. 并发优化锁、伪共享、线程模型三个现场复现都值得自己跑一遍4.1 锁竞争的本质是排队不是锁本身并发优化是系统性能优化里最容易写出行之有效技巧的部分也是最容易拍脑袋的部分。很多人觉得“锁慢”是因为加锁这个操作本身有成本。其实互斥锁在无竞争时的一次加锁解锁只有几十纳秒真正常态几百倍开销的是锁竞争引发的线程睡眠、唤醒、上下文切换。一个典型的场景8 核机器开了 16 个线程每个线程处理任务时都要抢同一把锁。核心观察是线程 A 持有锁处理任务线程 B 抢锁失败进入睡眠线程 A 释放锁并唤醒线程 B线程 B 被唤醒后要重跑调度器、恢复上下文此时 L1/L2 缓存里全是其他线程留下的数据缓存命中率骤降。这一整套过程单次看起来只有微秒级但在高并发下会像高速公路的收费站一样形成排队效应。你会看到 CPU 用量不低但业务吞吐就是上不去——大量 CPU 时间花在锁的排队和调度上。优化的优先级应该是能不共享就不共享比如 thread-local 变量缩小临界区只在最短执行路径上加锁换更合适的同步原语原子变量、读写锁、无锁队列最后才考虑锁的底层实现优化。4.2 false sharing一个经典且隐蔽的性能杀手这个知识点几乎每次 CPP 技术峰会都会出现因为它是“多线程下看起来毫无道理地慢”的头号元凶。问题背景两个线程分别操作两个不同的原子变量听起来互不干扰但这两个变量如果恰好落在同一个 64 字节 cache line 里情况就变了。CPU 的缓存一致性协议要求当一个核心修改了某个 cache line 上的数据时其他核心持有该 cache line 的副本必须作废。于是两个本该各写各的线程会因为共享 cache line 而不断互相“踢下线”形成无意义的同步流量。现场 demo 复现过这个场景两个线程各自对一个std::atomicuint64_t做累加结果共享同一个缓存行时吞吐下降了一个数量级。修复方式非常简单#include atomic #include cstdint // 错误两个 Counter 对象很可能落在同一 cache line struct Counter { std::atomicuint64_t value{0}; }; // 修复按 cache line 大小对齐保证每个对象独占缓存行 struct alignas(64) CounterAligned { std::atomicuint64_t value{0}; }; CounterAligned counters[2]; // 线程 0 操作 counters[0] // 线程 1 操作 counters[1]alignas(64)在这里的意义是让每个CounterAligned对象占用独立缓存行。如果你的 C17 编译器支持std::hardware_destructive_interference_size可以用它代替硬编码的 64不过很多环境需要手动定义宏用alignas(64)反而是最保险的通用做法。这个坑特别隐蔽的点在于它不是逻辑错误不开启任何 sanitizer 都查不出来它只在特定机器、特定内存布局、特定线程数量下触发。排查手段也很依赖 profiler 的缓存事件统计比如perf stat -e cache-misses, cycles对比不同版本。所以我在项目里看到“多线程版本反而比单线程慢了一半”的第一反应现在就是检查 cache line 是否被打崩。4.3 线程模型多开线程不等于更快“我用多线程重写了每核一个线程为什么不快反慢”这是 session 问答环节出现频率最高的问题。原因有两层。第一层是前面说的线程多了之后锁竞争、缓存在核心之间横跳、调度开销都会上涨。第二层是线程创建与销毁本身是昂贵的每次创建线程要分配栈空间、建立内核调度实体销毁时还要回收。如果任务生命周期很短创建线程的成本可能比任务执行本身还高。正确思路是固定数量线程池线程数一般不超过硬件线程数超线程可以适当放宽不用管任务本身的生命周期IO 密集型场景考虑协程C20 有了coroutine标准支持再加上无栈协程方案可以让海量 IO 任务共用一个线程避免海量线程的调度开销无锁队列适合单生产者单消费者boost::lockfree::spsc_queue或者自研 MPSC 队列在非泛化场景下效果显著但别为了炫技而用。会议上总结的一句话我记下来了能用线程池解决的问题别直接用裸线程能用协程解决的问题别硬上更多线程。5. 没有度量一切都是猜测perf 和火焰图的一线排查实操5.1 先压测再优化否则你连问题在哪都不知道这一节我想把重心完全放在实践上。因为性能优化领域最大的错误不是优化错了而是直接动手优化连 baseline 都没有。我自己的标准流程分四步压测用wrk、ab或自研压测脚本确定当前吞吐、P50/P95/P99 延迟记录下来当作基线采样用perf等 profiler 采集 CPU 热点、锁等待、缓存行为假设根据采样结果列出候选瓶颈按“影响面 × 修复成本”排序验证每改一处重新压测对比 baseline决定保留还是回滚。这四步的纪律非常重要。我见过太多人一上来就把unordered_map换成更花哨的数据结构结果瓶颈根本不在查找本身压测数据证明性能纹丝不动——浪费了时间还增加代码复杂度。5.2 perf 工具链速览从 top 到 recordLinux 上首选工具就是perf它基于内核的硬件性能计数器开销极低适合线上的第一轮抽丝。最基本的三个命令# 1. 实时观察进程内最耗 CPU 的函数 perf top -p $(pgrep your_app) # 2. 统计周期内整体的缓存命中、IPC、上下文切换概况 perf stat -e task-clock,cycles,instructions,cache-misses ./your_app # 3. 记录完整调用栈用于事后生成火焰图 perf record -F 99 -g -- ./your_app perf report --stdio-F 99的含义是每秒采样 99 次这是 Brendan Gregg 经常推荐的频率既能得到足够采样点又避免因采样频率过高反过来影响被测程序。-g表示记录调用栈。perf report输出里Samples列的占比就是该函数在采样周期内的 CPU 时间占比。切记不要只看函数名还要看它的调用路径caller chain——同一个函数可能是被完全不同的两层路径调用的。5.3 火焰图读法别被入口函数骗了火焰图是性能分析最直观的呈现形式生成命令也不复杂git clone https://github.com/brendangregg/FlameGraph perf script | ./FlameGraph/stackcollapse-perf.pl | ./FlameGraph/flamegraph.pl flame.svg读火焰图有三个我特别想提醒的误区看宽度不看高度x 轴是采样占比所以“最宽”的那层函数才是真正吃 CPU 的主体。很多时候入口函数最顶层看起来巨大但真正热的是它调用链路深处某个叶子函数平顶栈是最佳目标如果一块区域呈现宽而扁的特征说明热点就在那一层自身代码里业务逻辑吃掉了大量 CPU这是最容易优化的地方考虑算法、SIMD、缓存布局不要盯着“看起来应该慢”的函数真正快的路径压根不会出现在火焰图的宽条区域里出现在宽条里的往往是你没想到的地方。补充几个适合不同场景的分析工具表格汇总如下工具适用场景备注perfCPU 热点、缓存事件、调用栈最有通用性先学它valgrind --toolcachegrind模拟缓存命中、分支预测适合离线分析小规模程序heaptrack/valgrind --toolmassif内存分配次数与内存堆积定位分配器瓶颈的大杀器Tracy/Perfetto可视化帧/任务级时间线适合客户端、游戏引擎的帧耗时分析gdb或strace挂死、系统调用异常排查问题用不是测性能用的6. 两个生产案例复盘系统调用批量化和缓存友好改造6.1 案例 A网络包处理路径上的系统调用消除我在峰会上记下的第一个案例是一个网络代理模块的性能问题。现象很明确单核吞吐上不去CPU 用量却不低。perf record之后发现样本里有相当大比例的耗时集中在recvfrom和sendto两个系统调用上。问题不仅仅是被调用的次数多而是每次系统调用都伴随用户态/内核态切换、寄存器上下文保存恢复、页表和指令缓存的干扰。高频系统调用会让流水线反复被“切断”。修复方案很经典把单包收发改成批量收发。// 优化前一个包一次系统调用 for (int i 0; i batch; i) { recvfrom(fd, pkt, len, ...); process(pkt); sendto(fd, out, len, ...); } // 优化后批量收、批量发大幅减少系统调用次数 recvmmsg(fd, msgvec, batch, MSG_WAITFORONE, NULL); for (int i 0; i batch; i) { process(msgvec[i].msg_hdr); } sendmmsg(fd, msgvec, batch, 0);现场给出的实测数据是系统调用次数下降了接近一个数量级视包大小不同从几十倍到几倍不等整体吞吐提升约 25%~30%。注意它的收益不在单个系统调用变得更快而是把整个处理流程从“频繁被打断”变成“连续工作”。这个案例给我的通用启发是如果你的热点栈里出现大量系统调用底层的函数如 syscall、entry_SYSCALL_64优先考虑减少调用次数而不是纠结系统调用本身的实现。常见的方案还有用户态缓存、合并小包、用io_uring做异步批量提交等。6.2 案例 B批量任务尾延迟的缓存友好改造第二个案例来自一个批量任务执行系统。需求是处理大量短任务每个任务包含一个 ID、若干字段、一个处理状态。最开始实现是每个任务一个对象塞进std::unordered_mapint, Task处理时按 ID 查找更新。现象是吞吐尚可但P95 延迟非常高而且任务量一上来P95 增长比 P50 快得多。排查后发现核心问题不是 unordered_map 本身的查找复杂度而是它的内存布局极度分散每个 Task 对象在堆上各自分配桶数组和节点链表又把数据打散到不同内存页。处理任务时CPU 每访问一个新任务几乎都在 cache miss还在分配新节点时触发了 malloc 的元数据开销。修复方案是把任务存储改成连续数组 紧凑索引// 优化后任务本体用连续 vector 存储 struct Task { uint64_t id; uint8_t status; // ... 其他字段 }; std::vectorTask tasks; // 连续内存顺序遍历时天然缓存友好 std::vectoruint32_t index; // 按某种顺序存储任务下标由于任务处理路径主要是按批次顺序遍历这个改动让 P95 延迟直接降了约 4 倍从 8ms 降到 2ms 左右。复杂度没变但内存局部性好了一个数量级。这个案例特别适合跟第 3 节的“数据结构就是性能设计”呼应。当你的热点循环是顺序遍历大量对象时连续数组永远比散列容器友好只有当“随机查找”才是主路径时哈希表的 O(1) 才有意义——而即便如此也建议用开放寻址法robin-hood hashing或flat_hash_map保持缓存局部性尽量不要用链表式实现。6.3 两个案例的共通逻辑与我的个人体会这两个案例表面上毫无关系一个消灭系统调用一个改造内存布局但底层逻辑一致性能优化的本质是消除浪费——减少等待、减少搬运、减少同步。网络代理案例减少的是“等待内核切换”的浪费任务系统案例减少的是“等待数据从主存搬进缓存”的浪费前面的锁优化、分配器优化减少的是“等待其他线程”和“等待分配器元数据”的浪费。如果非要用一句话概括这次 CPP-Summit 学习笔记第四篇的核心系统性能优化从来不是某个单一技巧的堆砌而是一套“度量—假设—验证”的工程方法加上对 CPU、内存、并发三种资源的系统性理解。我在会后的实际项目里已经按这套流程完整走了一遍效果比我以前凭感觉优化靠谱太多。如果你也是刚从配好环境、跑通 C/C 程序的阶段走出来我建议你现在就装上perf拿自己的项目跑一次perf record -F 99 -g看着火焰图你会发现一个全新的世界。