性能优化这事最容易栽的跟头不是不会优化而是拿肉眼看代码猜热点。我身边不少同事包括我自己刚入行那两年都干过把一段根本不在热路径上的代码改得面目全非结果跑一遍 profiler 才发现主要时间开销根本不在那儿。C 性能优化的核心其实是三个步骤量一下、改一改、再量一下。网上流传的“十大技巧”很多今天这篇不是简单罗列而是把我这几年代码优化实战中最常用、性价比最高、踩过坑最多的十个方向整理出来。覆盖编译选项、容器与内存、字符串、传参方式、算法与数据布局、并发处理以及最后怎么定位瓶颈。适合已经能用 C 写业务、但总觉得速度不够快的开发者也适合想把算法题跑进时限的竞赛入门选手。每个技巧我都会说明为什么有效、什么时候别用以及我实际遇到过的问题。1. 先别动代码把编译选项的潜力榨干很多优化其实在写代码之前就已经决定了。同一份源码用不同的编译选项跑出来的性能可能差出好几倍。我见过不少人花大力气手工展开循环、手写汇编结果一看编译指令连最基本的优化等级都没开这种属于典型的捡芝麻丢西瓜。1.1 优化等级从 -O2 开始别一上来就 -O3GCC 和 Clang 都提供了 -O0、-O1、-O2、-O3、-Os 这几个优化等级。调试阶段用 -O0 没问题符号完整、单步调试不乱跳。但发布版本如果不加优化等级等于让编译器用最保守的方式生成代码很多本该内联的函数没内联循环也没有向量化性能自然上不去。我默认给 Release 用 -O2不是 -O3。原因是 -O3 会做更激进的内联和循环展开代码体积通常明显膨胀指令缓存吃紧的场合反而可能变慢。有时候 -O3 能把计算密集型代码压榨得更狠但到底有没有收益必须以实际压测结果为准不能拍脑袋。如果项目跑在存储受限的嵌入式环境用 -Os 更合适它是以体积优先代价是速度略低。这里给你一段我在 CMake 里常用的配置if(CMAKE_BUILD_TYPE STREQUAL Release) add_compile_options(-O2) endif()如果是命令行直接编我常用的是g -O2 -stdc17 -Wall main.cpp -o app1.2 开启链接时优化 LTO 与目标指令集LTOLink Time Optimization和常规编译优化不是一回事。普通编译单元之间是“井水不犯河水”的每个 .cpp 文件单独生成目标代码链接阶段没法跨文件做内联和常量传播。LTO 解决了这个问题它把中间表示保留到链接阶段让整个程序作为一个整体去优化。开启方式也很简单GCC 加 -fltoClang 加 -fltoMSVC 对应 /GL 和 /LTCG。我实测过一个日志解析项目只加 -flto 就带来 5%~10% 的稳定性能提升代价是编译时间变长、内存占用变大。大型项目可以考虑只在 Release 构建开启。指令集方面-marchnative 可以让编译器针对当前 CPU 的指令集生成代码比如 AVX2、AVX-512。这在本地跑没问题但如果你的二进制要分发到其他机器就要慎重了。我踩过的一个坑是在支持 AVX-512 的开发机上编译完丢给一台老服务器跑直接报 Illegal instruction后来统一改成 -marchx86-64-v3 才解决既带走大部分新指令集收益兼容性也保住了。1.3 Release 构建里关掉多余的运行时检查这个点常被忽略。很多项目在生产环境还带着一大堆断言、日志开关、或者默认开启的异常检查这些都属于运行时成本。NDEBUG 宏会在标准库很多地方触发行为变化比如 assert 直接展开成空操作、一些边界检查消失。我见过一个项目Release 忘定义 NDEBUG结果一大串 assert 在热循环里被反复求值白白丢掉接近 20% 性能。CMake 的 Release 配置默认会加 -DNDEBUG但如果你自己搭的构建脚本没带就得手动确认。另外如果项目确实不需要异常处理和 RTTI可以加 -fno-exceptions -fno-rtti减小二进制体积、减少分支开销。但这属于“大改”假如依赖的第三方库内部依赖异常关掉会比较痛苦。我在一个纯计算模块里用过效果不错但放在业务系统里我一般不敢随便关。优化不是比谁关得多而是比谁关得准。提示任何编译选项的改动都必须跑一遍完整回归测试。性能优化不能以正确性作为牺牲品。2. 容器与内存分配别让隐藏的分配拖垮你如果说编译选项是热身那么容器和内存就是正式比赛了。C 开发者对 STL 容器都很熟但真正理解“分配开销”和“缓存行为”的并不多。在热点路径上一次无谓的 new/delete 可能比一万次普通运算还贵。2.1 vector 默认当选但要学会 reserve很多新手用 vector 的习惯是边 push_back 边让它自己增长。vector 的扩容是指数策略翻倍预留新空间、把老元素搬过去、释放旧空间。元素类型越复杂、数量越大这个搬迁成本就越可观。正确姿势是在明确数据量的时候提前 reserve。比如我知道一个文件大概有一万行那就先vectorstring lines; lines.reserve(10000);直接省掉多次重新分配和元素移动。这个优化成本极低收益非常直观。我自己习惯用一个小工具函数在压测前统计 vector 的 capacity 变化一旦发现 capacity 增长次数太多就说明 reserve 用得不够。还有一点vector 的 clear 不会释放 capacity如果你要复用一个 vector直接 clear 然后再用能省去重新分配的时间。2.2 红黑树还是哈希表先看你的操作画像map 和 unordered_map 的选型是容器优化里最经典的问题。map 基于红黑树插入、查找、删除都是 O(log n)但它内部节点是离散分配的缓存命中率低。unordered_map 基于哈希表平均 O(1)哈希冲突少的时候很快。但“O(1) 一定比 O(log n) 快”这个直觉是有害的。数据量小的时候哈希函数计算和取桶操作的固定开销可能比红黑树的几次比较还高unordered_map 反而更慢。另外哈希表的连续内存特性意味着一旦发生 rehash所有元素都要重新哈希、重新存放瞬间开销很大。我一般这样选需要有序遍历、或者范围查询用 map没有顺序要求、数据量大、查找为主用 unordered_map。还有一招是提前 reserve 桶数量比如unordered_map的reserve能显著减少 rehash。对于固定键集合甚至可以考虑开放寻址的自定义哈希表性能比标准库里拉链式的实现再上一个台阶。不过这属于“进阶玩法”新手别一上来就手搓哈希表先把标准库用透再说。2.3 高频创建销毁小对象时内存池才是解药业务代码里最常见的一类性能黑洞在循环里反复创建小对象用完就丢。每次构造、析构都要走一次分配器如果是多线程环境还可能触发锁竞争。我在一个网络网关项目里干过这事每收到一个报文就 new 一个小结构体处理完 delete。QPS 一高内存分配直接成为瓶颈。后来改成固定大小对象池预先分配一批节点空闲的挂链表用的时候摘一个用完还回去。压测结果延迟从几十毫秒降到毫秒级吞吐翻倍。自己实现对象池核心就是两个接口acquire 和 release外加一个空闲链表的原子 push/pop。如果不想手写也可以用 boost.pool 或 mi_malloc 这类成熟库。需要提醒的是内存池适合“大小相对固定、生命周期短”的对象如果是大小差距悬殊的通用内存请求内存池意义不大老老实实优化分配频率反而更有效。3. 字符串处理十行代码九个坑字符串是 C 里最庞大的类型家族之一也是最容易写出隐藏开销的地方。std::string 本身没问题问题在于很多人没搞清楚它内部做了什么。热搜词里“c字符串数组初始化”和“c字符串转数组”出现很多次说明大家经常在这里绕路。这一节就把字符串相关的坑逐个说透。3.1 拼接字符串时先留好余量std::string::operator本身是个好接口但如果你在一个循环里不停地 短字符串string 会因为长度增长而多次重新分配内部缓冲区。每多一次分配就有一次 copy 和 free循环体越大浪费越明显。解决方案很朴素先把最终长度估算出来然后 reserve。比如我要构造一个 SQL 插入语句字段很多我会先把固定片段和可变长度估计一下提前给 string 留出空间。这样循环里的 基本不再触发重新分配速度提升往往非常明显代码改动量却很小。std::string sql; size_t estimated 26 field_count * 16; sql.reserve(estimated); sql INSERT INTO t VALUES (; for (size_t i 0; i field_count; i) { if (i) sql , ; sql field_values[i]; } sql );;还有个细节频繁拼接时优先用operator或append不要用str str xxx。前者是直接在现有字符串上追加后者会构造一个临时 string临时变量用完还要销毁又多一次拷贝。3.2 只读字符串参数用 string_view别再做无谓深拷贝传参时如果函数只需要读取字符串内容传const std::string通常没问题但如果你在跨函数传递链比较长或者字符串会从临时对象转换过来就可能产生不必要的拷贝。C17 引入的 std::string_view 是干这个事的它只保存指针和长度不拥有数据构造和拷贝成本极低。接收方只读字符串内容时用std::string_view替代const std::string可以从根上避免很多深拷贝。void parse_config(std::string_view sv) { // 只读 sv不修改、不外传 }需要注意string_view 不保证以 \0 结尾它只管 length 个字符。我从旧代码迁移时踩过一个大坑原来代码依赖字符串隐式转换到 const char* 再交给 C 接口换成 string_view 后那些 C 接口直接越界读了非常危险。所以 string_view 只用于“你确定不会在内部转成 C 字符串”的场合。生命周期的坑更常见string_view 指向的字符串被销毁或修改view 就成了悬垂指针使用时要格外小心。3.3 初始化字符串数组或转数组时提前规划空间很多人初始化一个vectorstd::string直接按文本解析往里面 push_back。如果这个数组是要被高频遍历或传递的建议先做好空间规划。一种做法是上面提到的 reserve另一种是用字符串数组构造时避免逐字符 push_back。比如把一个std::string转成std::vectorchar或std::arraychar,N大忌是先 push_back 再反转。正确做法是直接用std::copy(str.begin(), str.end(), dst.begin())或者对长度已知的数组直接用 memcpy 逻辑。实测下来同样长度的一万次转换直接 copy 比逐字符 push_back 快出一个数量级。另外如果你在封装 C API对外返回字符串数组时用vectorstring其实很容易触发拷贝。更高效的做法是返回std::vectorstd::string_view如果字符串容器生命周期足够长或者干脆用连续的char缓冲区加索引表。这块算是进阶优化但一旦用对收益立竿见影。4. 传参方式引用、指针、值传递的隐藏开销“c 引用 指针 和 值传递”是搜索热词说明很多人对传参开销的理解停留在“值会复制”这个层面。但具体哪些类型该按值、哪些该按引用很多老手也容易凭感觉拍脑袋。这里讲一个我自己的决策框架。4.1 大对象用 const 引用小对象直接按值一个简单的经验法则如果对象是基本类型或者体积只有几个字节直接按值传省一次间接寻址如果对象是大容器、大字符串或者任何拥有堆内存的类默认用const T。为什么会这样按值传参要把整个对象复制一份复制大容器意味着深拷贝里面的数据而按引用传参只是复制一个指针成本几乎为零。可如果你反过来对小类型都用 const 引用编译器也未必能优化掉间接寻址开销反而可能让代码更慢。那“大”和“小”的边界在哪我一般参考 ABI 和寄存器个数两个 64 位整数以内按值划算再大就倾向 const 引用。当然具体还要看复制构造函数成本string 很小但深拷贝成本高所以照样算“大对象”。4.2 返回值优化与移动语义让编译器帮你省掉拷贝从函数返回一个字符串或容器时大多数人第一反应是“会拷贝一次”。现代 C 已经不太一样了。C17 开始返回值优化RVO成为标准要求很多临时对象可以就地构造完全不拷贝不移动。返回局部变量时直接return local;即可编译器会尽量做 NRVO。如果为了“保险”手动写成return std::move(local);反而可能关闭 NRVO把本来能省略的拷贝变成一次移动属于真正的性能负优化。我在 code review 里经常看到这种每次都要提醒。该用 std::move 的地方也有比如把局部对象放进容器时std::vectorstd::string v; std::string s hello; v.push_back(std::move(s)); // s 的内容被“偷”走移动之后 s 处于“合法但未指定”的状态可以析构、可以重新赋值但不能假设它还保存原字符串。这个纪律一定要守住否则容易在复杂的生命周期里埋 bug。4.3 指针带来的缓存代价能连续就别散开传参方式里还有一类隐蔽成本当你的代码里到处是指针、引用、或者各种容器迭代器时哪怕传参本身便宜解引用时也可能频繁触发缓存未命中。链表和 vector 的对比是最典型的例子。链表每个节点存储在堆上不同位置遍历时 CPU 缓存大概率每次都要去内存里重新加载vector 元素连续存储在内存里遍历时大部分数据都能从 L1/L2 缓存直接命中。数据量大时vector 遍历比链表快出好几倍。所以如果只是读数据优先考虑连续内存的数据结构。如果确实要用指针尽量把指针指向的数据也放在同一块连续缓冲区里或者用数组下标代替指针这也是很多游戏引擎常用的“数据导向设计”。5. 算法优化与数据布局从源头降复杂度光靠编译选项和容器优化顶多是把常数因子变小。想要质变得回到算法层面。搜索热词里的“冒泡排序算法c”、“快速幂算法c”、“单调栈算法c”其实都是同一个主题把复杂度降下来。5.1 排序场景小数据量别被快排的复杂度忽悠很多人一听到排序就想到快排因为平均 O(n log n)。但如果你要排序的数据只有几个元素插入排序这种 O(n²) 的简单算法反而更快因为常数极小、几乎没有额外开销。标准库里的 std::sort 其实也在做类似的事当递归区间小于一定阈值时会切换成插入排序。我在一个配置解析模块里就干过这事结构体数组只有十几个元素原来用 std::sort后来改成手写插入排序性能提升虽然不算巨大但省了一个函数调用链代码也更清晰。反过来如果数据量是十万级千万别手写冒泡排序直接快排或者基数排序才是正道。5.2 高频路径上的剪枝与单调栈/二分算法优化的另一个维度是“能不能少算”。快速幂的价值在于把 O(n) 次乘法变成 O(log n) 次在大指数和大数取模场景中收益巨大。单调栈的价值在于把“找下一个更大元素”这类问题从 O(n²) 降到 O(n)很多看似只能暴力的题用单调栈一遍扫描就解决。这类技巧看起来像竞赛专属实际业务里也很常见。比如处理时间序列数据要找一个元素之后的第一个更高价格暴力是双重循环用单调栈能轻松跑完千万级数据。再比如有序数组查找能用二分就二分别用线性扫描。这些都是“高杠杆”改动只改算法不动数据结构复杂度直接降一个量级。5.3 数据布局决定缓存命中率AoS 与 SoA如果你的热点循环在遍历一个结构体数组比如粒子系统、像素列表、数据库记录数据布局的优劣可能带来几倍性能差。结构体数组AoS是把每个对象的所有字段挨在一起存储符合人的直觉。数组结构体SoA是把所有对象的同一个字段放在一起即“字段数组”。SoA 对缓存更友好因为循环里通常只访问某一两个字段SoA 能让这些字段在内存里紧密连续一次加载就能喂饱后续很多次运算。我在做图像处理时试过把 RGB 像素从 AoS 改成 SoA单个字段的批量计算速度直接上了一个台阶。如果你的热点循环只处理结构体里的少数成员完全可以考虑 SoA 布局。这个改动会带来代码风格上的不习惯但性能收益值回票价。6. 多线程并发优化锁、原子操作与线程池多线程优化是最容易“看起来对了用起来更慢”的领域。搜索热词里有很多“tdengine, c绑定写入数据库”之类的场景这类问题本质是 IO 与 CPU 并发调度。多线程不是开得越多越快关键是锁、原子操作和任务模型。6.1 锁粒度与锁竞争别给临界区加戏锁竞争和临界区大小直接相关。临界区越大别的线程等得越久临界区太小频繁加锁解锁本身开销又大。这个平衡要靠实测但有一个大方向临界区只保护真正需要保护的数据别把无关的计算也塞进去。我一个数据库写入场景是这样的多个工作线程生成日志由一个专用线程负责批量写入数据库。如果每个工作线程写完就立刻加锁写库锁竞争非常严重。后来改成生产者-消费者模式工作线程把日志塞进一个无锁队列专用线程批量消费并落库。这样锁基本没冲突吞吐量反而成倍增长。另外读多写少的场景用 std::shared_mutex读写锁替代 std::mutex多个读者可以并行写者独占。但要注意如果写操作非常频繁读写锁的锁开销可能比普通互斥锁更大需要实测后决定。6.2 原子操作与内存序的合理使用std::atomic 在处理计数器、标记位这类场景里比互斥锁便宜得多。单纯加一个计数器用atomicint的 fetch_add比加锁再解锁快不少。内存序这个东西大家常用的是 seq_cst顺序一致语义最安全但性能开销也最大。在某些只需要保证“最终一致”的场景memory_order_relaxed就够了。比如统计线上请求次数不要求每次读取都精确同步用 relaxed 能省掉不必要的内存屏障。但对于“锁释放-获取”这类关系必须用 acquire/release绝不能用 relaxed。我见过有人图快到处 relaxed结果跨线程共享状态全乱套调试两天才找出问题。原子操作是精细工具能用对内存序前宁可先用保守的 seq_cst。6.3 线程池与 IO 线程分离频繁创建和销毁线程既慢又消耗系统资源。正确做法是预创建固定数量线程用任务队列分发任务。线程数最好等于 CPU 核心数如果是 IO 密集型可以适当多几个让等待 IO 的线程不阻塞 CPU 核心。对于写数据库这类 IO 操作强烈建议把 IO 操作从计算线程里剥离出去。我在一个服务里是把“解析报文”和“写入数据库”拆成两个线程解析线程只管计算写库线程通过队列收数据、批量提交。这样即使数据库偶发抖动也不会拖住整个服务主流程。实际压测下来在数据库延迟波动 100ms 时原方案整体吞吐掉 30%拆线程后只掉 5%。7. 性能排查方法论先测量再优化技巧说了一大堆最后还是要回到工具和方法。不会定位瓶颈就是把所有技巧都背下来也用不上。这里分享一套我常用的排查流程核心就一句话不测量等于瞎调。7.1 建立可重复的基线给优化留底优化之前先写一个能复现问题的压测用例。这个用例必须稳定、可重复、覆盖真实使用模式。我常用一个简单的 stopwatch 封装统计耗时平均值、最小值和 P95。只看平均值容易被极端值带偏P95 能更真实反映用户感知。需要注意编译器优化可能把“没用的计算”优化没所以基准测试里不能只算结果不看不存。我一般用一个全局 volatile 累加器来防止整个计算被优化掉。这一步是关键很多人写的 benchmark 测出来的数据根本不反映真实代码。volatile int sink; void benchmark() { auto start std::chrono::steady_clock::now(); for (int i 0; i N; i) { result compute(i); sink result; // 防止整个循环被优化掉 } auto end std::chrono::steady_clock::now(); }7.2 热点定位用采样而不是猜拿到基线之后用 perfLinux或 Intel VTuneWindows/Linux做热点采样。perf top 能直接看到哪些函数正在占用 CPUperf record 可以生成报告。perf record ./app input.txt perf report我遇到过最典型的一次同事花了三天把所有字符串拼接都改成 string_view性能提升微乎其微。后来 perf 一跑真正热点是一个大概只有两百行的解析函数里面有个 O(n²) 的查找逻辑。改掉这一处之后整体提升 30%。这个案例被我当组内反面教材反复讲性能优化最大的成本是时间最大的敌人是“想当然”。7.3 常见性能症状速查表症状可能原因优先检查项CPU 跑满但吞吐低算法复杂度太高热点函数、循环嵌套多线程下吞吐不升反降锁竞争严重、开启线程过多锁粒度、线程数内存增长明显、性能波动高频 new/delete、容器频繁扩容分配频率、reserve 使用字符串处理慢反复拷贝、深拷贝传递string_view、reserve数据量大时遍历变慢缓存命中率低数据布局、容器类型延迟偶尔飙高IO 阻塞计算线程IO 线程分离、批量提交单个操作很快但总量很慢函数调用次数过多、内联失败小函数是否内联、编译选项这张表不能替代 profiler但它能帮你把怀疑方向快速收窄省掉不少盲目尝试。最后分享一点个人心得。我见过很多性能优化项目最后真正成功的不是把某个函数提升 50 倍那种一锤子买卖而是建立了一套“改动有数据、回归有基准”的工作节奏。我每次优化提交至少保留三样东西优化前后的基准测试脚本、当时的采样报告、以及对关键代码的注释。这比任何技巧都重要。我在实际项目中还会专门维护一个 baseline 目录每次优化的第一步永远是跑同一套压测场景改完之后立刻复测。看起来有点繁琐但踩过几次“优化了个寂寞”的坑之后你就会明白这才是整个性能优化流程里最省时间、最不容易翻车的做法。