27. 大型项目性能优化案例：游戏引擎优化、高频交易系统优化、数据库内核优化

说实话，做了这么多年性能优化，最让我兴奋的其实是大型项目的实战。小模块优化，你调个循环、改个数据结构，效果立竿见影。但到了游戏引擎、高频交易、数据库内核这种量级，问题就复杂多了。

我参与过几个这类项目，踩过不少坑。今天就把三个典型场景的优化思路拆开来讲。你想想看，这些场景虽然领域不同，但底层的优化逻辑其实是相通的。

游戏引擎优化：从卡顿到丝滑

游戏引擎的优化，核心就两个字：帧率。玩家不会关心你用了多牛的数据结构，他只关心画面卡不卡。我优化过一个自研引擎的渲染管线，当时场景里物体一多，帧率直接掉到20以下。

CPU侧的瓶颈：Draw Call 合并

问题出在哪？Draw Call 太多了。每帧几千次调用，CPU 忙着切换状态，GPU 反而在空转。说白了，CPU 成了瓶颈。

我当时做了一件事：批处理。把相同材质、相同网格的物体合并成一个批次渲染。代码大概长这样：

// 优化前：每个物体单独绘制
for (auto& obj : scene_objects) {
    RenderMesh(obj.mesh, obj.material, obj.transform);
}

// 优化后：按材质分组，合并绘制
auto batches = GroupByMaterial(scene_objects);
for (auto& batch : batches) {
    BindMaterial(batch.material);
    for (auto& instance : batch.instances) {
        UploadTransform(instance.transform);
    }
    DrawInstanced(batch.mesh, batch.instances.size());
}

效果很明显。Draw Call 从 3000 降到了 200，帧率直接翻倍。嗯，这里要注意：合并不是无脑的，你得考虑物体是否共享材质和网格。

GPU侧的优化：LOD 与遮挡剔除

CPU 搞定了，GPU 又成了新瓶颈。场景里远处的小物体，你还在用高精度模型渲染，这不是浪费吗？

我引入了LOD（层次细节）系统。距离远了，自动切换低精度模型。同时加上遮挡剔除——被墙挡住的东西，压根不渲染。

高频交易系统优化：纳秒级的战争

高频交易系统，我接触得比较晚。但一上手就被震撼了——这里的优化单位是纳秒。你多花 100 纳秒，订单可能就抢不到了。

内存布局：缓存友好是第一要务

我优化过一个订单簿引擎。最初版本用 std::map 存储价格档位，每次查询都要走树结构，缓存命中率极低。

改成什么？数组 + 跳表。把价格档位按顺序放在连续内存里，用跳表加速查找。这样 CPU 预取能命中，延迟从微秒级降到了纳秒级。

// 优化前：std::map 导致大量指针跳转
std::map<double, OrderList> order_book;

// 优化后：连续内存 + 跳表索引
struct PriceLevel {
    double price;
    OrderList orders;
};
std::vector<PriceLevel> levels;  // 连续存储
SkipList index;                   // 跳表加速查找

我曾经踩过一个坑：以为用 vector 就万事大吉了。但 vector 扩容时会重新分配内存，导致指针失效。后来我改用 pmr::vector，提前分配好固定大小的内存池，彻底避免了动态分配。

锁的代价：无锁队列

多线程环境下，锁是最大的敌人。我见过一个系统，90% 的时间花在锁竞争上。后来我们改用了 无锁队列（基于 CAS 操作），吞吐量提升了 5 倍。

但无锁编程不是银弹。我建议你只在热点路径上用，其他地方还是老老实实加锁。否则调试起来，你会怀疑人生的。

数据库内核优化：IO 与 CPU 的博弈

数据库内核优化，我最有发言权。我优化过一个开源数据库的存储引擎，主要针对 OLTP 场景。核心矛盾是：IO 太慢，CPU 太快。怎么让 CPU 等 IO 的时间变少？

Buffer Pool 管理：LRU 的改进

传统 LRU 算法有个问题：全表扫描会把热点数据挤出去。我遇到过这种情况——一个报表查询跑完，线上业务的响应时间直接翻倍。

怎么解决？LRU-K 算法。记录每个页面的访问频率，只把真正冷的数据淘汰掉。代码实现上，其实就是多维护一个访问计数器：

// 简化版 LRU-K 淘汰逻辑
if (page.access_count < K) {
    // 访问次数不够，不淘汰
    continue;
} else {
    // 按最后一次访问时间排序，淘汰最旧的
    evict_candidate = find_oldest_page_with_min_access();
}

效果呢？全表扫描对缓存的影响降低了 80%。

索引优化：B+ 树的变种

B+ 树是数据库的标配。但默认实现里，每个节点只存一个键值对，导致树太高，IO 次数多。

我改成了批量插入和节点预分裂。插入时攒一批数据再写盘，减少随机 IO。节点快满时提前分裂，避免写放大。

三个案例的共性：优化思维模型

你发现没有？这三个案例虽然领域不同，但优化思路高度一致。我总结了一个思维模型：

步骤	问题	方法
1. 定位瓶颈	CPU 还是 IO？	perf、火焰图、IO 监控
2. 减少无效计算	有没有做不必要的事？	LOD、遮挡剔除、缓存
3. 优化数据布局	内存是否连续？	数组、内存池、缓存行对齐
4. 减少锁竞争	多线程是否串行？	无锁队列、读写锁、分区
5. 权衡取舍	时间 vs 空间？	根据场景选择最优解

说白了，性能优化就是找到瓶颈，然后干掉它。但别一上来就优化，先问自己：这个瓶颈真的影响业务吗？我曾经花了一周优化一个冷门路径，结果线上根本没人用。嗯，那之后我学乖了——先 profiling，再动手。

好了，这三个案例就讲到这里。每个场景都有它的特殊性，但底层的优化哲学是一致的。你下次遇到性能问题，不妨先套用这个思维模型试试。我个人习惯是，先花 30% 的时间做 profiling，再花 70% 的时间动手优化。方向对了，事半功倍。