11 · 性能优化进阶

定位：游戏开发的第一追求就是性能——渲染、物理、AI 都要在 16.7ms（60fps）一帧内跑完。这章把“为什么 C++ 快/怎么让它更快”讲透：虚函数开销、缓存友好、内存池、分支预测，是面试加分项密集区。 学完标准：能回答“虚函数有性能开销吗、开销在哪”；能讲清 SoA vs AoS 和缓存友好；能说内存池/对象池原理；知道优化三步法（测量→定位→优化）。

---

1. 性能优化的第一原则：先测量，再优化

面试金句：“Measure, don’t guess”（先测量，别猜）。90% 的直觉优化是浪费；先找到热点，再动手。

优化流程（背下来）：

1. 测量：profiler 找到瓶颈（CPU 占比最高的函数）
2. 定位：区分“算法问题”（复杂度）和“常数问题”（内存布局、缓存）
3. 优化：先改算法/数据结构（收益最大），再做微优化
4. 复测：确认收益，防止负优化

工具（知道名字即可）：perf（Linux 采样）、Visual Studio Profiler / VTune、gprof、ASAN（内存错误）、valgrind --tool=callgrind。

游戏特有指标：帧时间（Frame Time）、P99 帧率（最低 1% 帧，卡顿感来源）、每帧预算分配。

---

2. 虚函数的性能开销（必考）

2.1 开销在哪三处？

开销	说明
间接跳转	每次虚调用要 ①取 vptr ②查虚表 ③间接跳转，比直接调用多 1~2 次内存访问
无法内联	动态绑定的调用编译器不知道具体函数，无法内联展开
分支预测差	间接跳转目标不固定，CPU 分支预测器预测失败率高（比直接 call 贵很多）

struct Base { virtual void f(); };
struct Derived : Base { void f() override; };

// 直接调用（可内联、预测友好）
Derived d; d.f();

// 虚调用（查虚表 + 间接跳转）
Base* p = getRandomObject();   // 运行期才知道是哪个派生类
p->f();                        // 每次都要查虚表

2.2 实际影响多大？什么时候才需要在意？

• 单次调用开销：约 5~15ns（vs 直接调用 1ns 量级）——单看微不足道
• 但每帧每物体调用（10000 个敌人 × 每帧几个虚调用）就累积成几毫秒
• 虚函数还阻止内联，内联往往是更大的优化来源（可能差 10 倍）

缓解手段：

1. 热路径（每帧高频调用）避免虚函数，改用：模板（编译期多态）、CRTP、switch 分发
2. ECS 思路：同类型数据连续排列，同一系统对同类对象做同一操作（无虚调用）
3. 数据驱动：把“行为”做成数据 + 统一处理逻辑，而非每个对象一个虚函数

面试金句：虚函数开销 = 一次间接跳转 + 丢失内联机会 + 分支预测变差；单次几乎无感，但每帧 × 海量对象时明显。游戏引擎的热路径普遍用“数据驱动 + 模板/ECS”替代虚函数。

---

3. 缓存友好（Cache Friendly）——性能的头号因素（重点）

3.1 现代 CPU 的真相：内存访问是瓶颈

CPU 寄存器        ~1  cycle
L1 缓存           ~4  cycles    (~1ns)
L2 缓存           ~12 cycles
L3 缓存           ~40 cycles
主内存            ~200+ cycles  (~100ns)  ← 慢 200 倍！

CPU 以“缓存行（Cache Line，通常 64 字节）“为单位加载内存：访问一个 int，实际把周围 64 字节一起搬进缓存。命中缓存 = 快，未命中（cache miss）要等主内存 = 慢 100 倍以上。

3.2 怎么做到缓存友好？（三招）

① 连续内存 + 顺序遍历（vector 完胜 list）

// ✅ 快：vector 内存连续，CPU 顺序预取，几乎全命中缓存
for (int i = 0; i < n; ++i) sum += v[i];

// ❌ 慢：list 节点散落内存各处，每次访问都可能 miss
for (auto it : list) sum += *it;

② SoA vs AoS（重点，游戏面试高频）

// AoS（Array of Structures）：对象数组 —— 整体连续，但同名字段交错
struct Particle { float x, y, z, vx, vy, vz; };   // 24 字节
std::vector<Particle> particles;                  // 位置和速度交织
// 只更新位置时，速度字段也被拉进缓存行（浪费带宽）

// SoA（Structure of Arrays）：数据按"字段"分开存 —— 同类数据连续
struct ParticleSystem {
    std::vector<float> x, y, z;       // 所有 x 连续
    std::vector<float> vx, vy, vz;    // 所有速度连续
};
// 只更新位置：只遍历 x/y/z 三个数组，缓存行里全是"要用的数据"

	AoS	SoA
布局	每个对象一个结构体连续排	每个字段一个数组
访问单个对象	方便	要跨数组
批量遍历单个字段	浪费带宽（拉到无关字段）	完美（缓存行全是目标数据）
典型场景	少量对象、对象整体使用	海量对象、按字段批量处理（ECS/粒子系统）

面试金句：SoA 让“同一时刻处理的所有数据”在缓存里挨着，是 ECS 与粒子系统性能的核心秘密之一。

③ 按访问顺序布局 + 数据对齐

• 把最常一起访问的数据放一起（class 热字段放前面）
• 对齐到缓存行（alignas(64)）避免字段跨缓存行
• 避免随机访问（哈希表、跳表访问模式分散）

3.3 一图总结

缓存友好：  顺序遍历连续数组  →  缓存命中率 ~100%  →  带宽跑满
缓存不友好：随机访问散落对象  →  cache miss 等待主内存  →  慢 10~100 倍

---

4. 内存池 / 分配器（游戏内存管理核心）

4.1 为什么要自己管内存？

• malloc/new 慢：通用分配器要维护空闲链表、加锁（线程安全）、可能系统调用
• 碎片化：频繁分配释放不同大小 → 堆碎片 → 浪费内存、分配更慢
• 缓存不友好：默认分配器返回的地址散落，对象分布无规律
• 游戏帧预算内必须可预测、可控制

4.2 常见分配器（知道概念即可）

分配器	原理	特点	场景
内存池 Pool	预分配固定大小块，空闲链表管理	无碎片、O(1) 分配	同类型对象（子弹、粒子）
栈式分配器 Stack	单一大块，游标后移，整体重置	极快、但一次性释放	每帧临时数据（帧内分配器）
线性分配器 Linear	同栈式，只增不减	极快	帧内一次性资源
双缓冲分配器	上一帧用的缓冲本帧释放	解决“用后即忘”	渲染提交数据
自由列表	释放对象挂空闲链表复用	对象池基础	见 10 章对象池

// 栈式分配器（核心思想，10 行）
class StackAllocator {
    char* buffer_; size_t size_; size_t offset_ = 0;
public:
    StackAllocator(size_t n) : buffer_(new char[n]), size_(n) {}
    void* alloc(size_t n) {
        void* p = buffer_ + offset_;
        offset_ += n;                    // 游标后移
        return p;
    }
    void reset() { offset_ = 0; }        // 整体重置，O(1) 释放
    ~StackAllocator() { delete[] buffer_; }
};

追问注意：示例只表达核心思想，没有处理内存对齐（new char[n] 不保证任意类型对齐）和越界检查；面试写完整版要加对齐处理和 offset_ + n <= size_ 断言。

4.3 内存池 vs 对象池（易混，必考）

	内存池	对象池
管理对象	原始内存块	已构造对象
是否调构造/析构	不（只有内存）	借还时重置状态（不析构）
用途	减少分配开销/碎片	复用高频对象生命周期

游戏里通常叠加：对象池内部用内存池分配内存，避免每个对象独立 new。

---

5. 分支预测（Branch Prediction）

5.1 是什么？

CPU 遇到 if 会猜走哪条分支（预测），猜对了零开销，猜错了要流水线清空重来（惩罚 ~20 个周期）。

// 数据有序 → 分支几乎总能预测对 → 快
std::sort(data.begin(), data.end());
for (int x : data) if (x > 500) sum += x;   // 快

// 数据乱序 → 预测随机命中 → 慢（可能差 2~5 倍）
for (int x : shuffled) if (x > 500) sum += x;   // 慢

5.2 怎么减少分支惩罚？

1. 排序数据让分支可预测（数据处理流水线常用）
2. 无分支写法（branchless）：用位运算/算术替代分支

// ❌ 有分支
int abs_v(int x) { return x < 0 ? -x : x; }
// ✅ 无分支（x>>31 是符号位全 1/全 0）
int abs_v2(int x) { return (x ^ (x >> 31)) - (x >> 31); }  // 依赖算术右移，主流平台 OK；标准严格说负值右移是实现定义的

3. 把高频分支放到前面（[[likely]] / [[unlikely]]，C++20 提示编译器）

if (fastPath()) [[likely]] { ... }     // 告诉编译器：这条分支更可能走

4. 查找表替代分支：table[value] 而不是 if/else if/else 链

注意：分支预测优化收益在现代 CPU 上越来越小（预测器很强），但乱序数据 + 高频分支的场景仍值得注意。先测量，别盲目炫技。

---

6. 其他性能手段速览

手段	说明	注意
内联 inline	函数体展开到调用处，省调用开销，暴露优化机会	大函数内联增大代码体积、可能伤缓存；让编译器决定（inline 只是建议）
移动语义	避免不必要的深拷贝（见 08 章）	配合 noexcept
SSE/AVX 向量化	一条指令处理多个数据（SIMD）	数学库、粒子、蒙皮；数据要对齐
多线程并行	多核利用（见 09 章 job system）	同步开销、数据竞争
避免虚函数	热路径用模板/switch 替代	见第 2 节
延迟计算	用到才算（惰性求值）、缓存结果	避免每帧重复昂贵计算
空间换时间	预计算表、缓存常用结果	内存够用的话很划算
减少分配	每帧避免 new/delete，用池/复用	分配器 + 池化

---

7. 高频面试题 Q&A（合上书能讲）

Q1：虚函数有性能开销吗？开销在哪？ 有：①查虚表 + 间接跳转（多 1~2 次内存访问）②无法内联 ③分支预测差。单次几乎无感，但每帧海量对象时明显。热路径用模板/ECS 替代。

Q2：什么是缓存友好？怎么做到？ 让访问的内存连续、按顺序遍历，CPU 缓存命中率高。做到：用 vector 不用 list、SoA 布局、按访问顺序排列字段、避免随机跳转。

Q3：AoS 和 SoA 区别？ AoS 一个对象一个结构体（整体访问方便）；SoA 每个字段一个数组（批量处理单字段时缓存行全是目标数据）。海量同构数据（粒子、ECS 实体）用 SoA。

Q4：为什么要内存池/对象池？ 避免 new/delete 的开销与碎片，预分配 + 复用，地址可控、可预分配连续内存（缓存友好）。游戏高频创建销毁（子弹/粒子）必用。

Q5：内存池和对象池区别？ 内存池管原始内存块（不调构造析构）；对象池管对象生命周期（归还时重置状态不析构）。常叠加使用。

Q6：分支预测是什么？怎么影响性能？ CPU 猜 if 走向，猜错流水线清空惩罚 ~20 周期。数据有序可预测则快，乱序随机则慢。缓解：排序、无分支写法、查找表、[[likely]]。

Q7：性能优化第一步是什么？为什么？ 先测量（profiler 定位热点）。因为直觉常常错，不测量就是盲目优化，可能负优化。

Q8：inline 一定能内联吗？ 不能，只是建议。编译器决定是否内联（过大、递归、虚调用都可能不内联）。现代编译器自动内联小函数，手动 inline 意义有限。

Q9：游戏一帧 16.7ms（60fps）怎么分配？ 渲染（可能一半）、游戏逻辑更新、物理、AI、动画、输入、UI 各占预算；超出预算就掉帧。P99 帧率反映卡顿感。

Q10：ECS 为什么性能好？（衔接 12 章） 同类型组件连续存储（SoA 缓存友好）+ 系统批量处理同类实体（无虚调用）+ 数据与逻辑分离（易并行）。

---

8. 本章自测（10 题，限时 20 分钟，先自己答再看答案）

1. 虚函数性能开销的三个方面？

2. 缓存行一般多大？为什么顺序遍历快？

3. 粒子系统为什么用 SoA 布局？

我的原答：写出 AoS 和 SoA 的 struct/字段示意。

4. 栈式分配器为什么能 O(1) 释放？

5. 内存池和对象池的区别？

6. 分支预测失败为什么慢？怎么缓解（至少 2 种）？

7. 性能优化的正确流程？

8. 为什么说"list 性能比 vector 差"？什么时候 list 反而合适？

9. 一个 int 数组顺序求和 vs 随机下标求和，差多少量级？为什么？

10. 游戏引擎为什么普遍自研/配置内存分配器？

📖 答案（先自己答完再展开）

1. 间接跳转（查虚表）、无法内联、分支预测差。
2. 64 字节。顺序遍历时数据几乎全在已加载的缓存行里，命中率高；随机访问频繁 miss。
3. SoA：位置数组、速度数组分开连续存；批量只更新位置时缓存行全是目标数据，不浪费带宽。示意见第 3.2 节。
4. 只移动游标，释放 = 整体重置 offset，不需要遍历归还空闲块。
5. 内存池管内存块（无构造析构），对象池管对象（借还重置状态）。
6. 猜错要清空流水线重取指令（~20 周期）。缓解：数据排序、branchless 位运算、查找表、[[likely]]。
7. 测量（profiler）→ 定位（算法 vs 常数问题）→ 优化 → 复测。
8. 节点散落内存、缓存 miss、无预取；list 适合“中间频繁插入删除且元素大、遍历少”的场景。
9. 可能差 10~100 倍。顺序访问命中缓存，随机访问频繁 miss 等主内存。
10. 通用分配器慢、有碎片、地址不可控；游戏需要帧内可预测、低碎片、缓存友好的分配，还能做帧级整体回收。

---

## 9. 进阶追问（答不上来就回来复习）

• 什么是 False Sharing（伪共享）？多线程各改一个变量为什么互相拖慢？（同一缓存行被多核争用）
• 什么是 TLB / 页表？为什么大数组遍历第一次慢？
• SIMD（SSE/AVX）怎么用？#pragma omp simd 或手写 intrinsic？
• 什么是 Profile-Guided Optimization（PGO，根据运行数据优化）？
• 缓存友好和 SoA 在 ECS 里怎么落地？（12 章详讲）
• 游戏里“每帧分配”的典型模式：帧分配器 + 双缓冲分配器怎么配合？