前面我们用 C 语言写了很多程序------从简单的计算器到链表、二叉树。它们能跑，结果也对。但"能跑"和"跑得好"之间，往往隔着一个叫性能的东西。
C 语言常被选来做系统编程、游戏引擎、嵌入式开发，一个核心理由就是它快 。但快不是免费的：同样的逻辑，不同写法速度可能差出十倍、百倍。今天这篇文章不是教你去啃复杂的算法分析，而是建立性能优化的意识：知道程序为什么慢，编译器能帮你做什么，以及你自己在写代码时应该留意哪些坑。
一、优化不是"凭感觉"：先测量，再优化
性能优化的第一条铁律：不要猜，要量。你以为慢的地方，可能根本不是瓶颈；你费劲优化了一行代码，结果它对整体运行时间只贡献了 0.1%。
C 标准库提供了一个简单的计时工具：clock()。
c
#include <stdio.h>
#include <time.h>
int main(void) {
clock_t start = clock();
// 要测量的代码
for (volatile long i = 0; i < 100000000; i++) { }
clock_t end = clock();
double seconds = (double)(end - start) / CLOCKS_PER_SEC;
printf("耗时: %.3f 秒\n", seconds);
return 0;
}volatile 告诉编译器不要优化掉这个循环。clock() 精度不高，但用于对比不同写法足够。更精确的测量可以用 gettimeofday（POSIX）或 QueryPerformanceCounter（Windows），但思想一致：用数据说话。
二、空间换时间 vs 时间换空间
这是优化中最经典的权衡。
1. 空间换时间：缓存计算结果
如果程序里反复计算同一个值，不如算一次存起来。
糟糕：每次都重新计算 Fibonacci
c
int fib(int n) {
if (n <= 1) return n;
return fib(n-1) + fib(n-2); // 大量重复计算
}fib(40) 要算上亿次函数调用。
改进：用数组缓存结果（备忘录法）
c
int cache[100] = {0};
int fib(int n) {
if (n <= 1) return n;
if (cache[n] != 0) return cache[n];
cache[n] = fib(n-1) + fib(n-2);
return cache[n];
}多用了内存（缓存数组），换来了指数级的速度提升。
另一个典型例子是查表法 ：如果某个函数输入只有有限几种（比如三角函数值），事先算好存数组，运行时直接 table[angle] 取值，比调用 sin() 快几十倍。
2. 时间换空间：用计算换存储
反向的场景也有。嵌入式设备内存只有几百 KB，存不下大表，那就在需要时实时计算。或者是处理大规模数据时，内存放不下全部数据，就用流式处理------一次只读一块，处理完扔掉，虽然 I/O 次数多了，但内存占用恒定。
实际开发中，"空间换时间"更常见，因为内存越来越便宜，而 CPU 速度增长放缓。但最终选择取决于你的目标平台和需求。
三、减少不必要的内存分配
malloc 和 free 是有代价的。每次堆分配都涉及系统调用、内存块查找、碎片管理。在一个每秒处理几十万请求的服务器里，频繁的 malloc/free 是常见的性能杀手。
1. 栈上分配 vs 堆上分配
如果数据大小在编译时已知，用栈（局部变量、数组）远比堆快。栈分配只是移动一下栈指针，函数返回时自动回收。
c
// 快：栈上分配
int arr[100];
// 慢：堆上分配
int *arr = (int*)malloc(100 * sizeof(int));
// ... 使用
free(arr);所以，小且生命周期短的变量，天然就该在栈上。
2. 对象池（Object Pool）
如果需要频繁创建和销毁同类型的结构体（比如链表结点、网络包），与其一个个 malloc/free，不如预先分配一块大内存，自己管理分配和回收。
简单示例：
c
#define POOL_SIZE 1024
typedef struct Node {
int data;
struct Node *next;
} Node;
Node pool[POOL_SIZE];
int pool_index = 0;
Node *node_alloc(void) {
if (pool_index < POOL_SIZE) {
return &pool[pool_index++];
}
return NULL; // 池耗尽
}这里不需要 free，池用完了整体回收即可。这种模式在游戏引擎、网络服务中极为常见，能大幅减少系统调用开销。
3. 警惕隐式内存分配
有些看起来无害的操作其实在背后分配内存，比如某些库函数内部使用 malloc。不过标准 C 库里大多数函数（strlen、memcpy、sprintf 等）并不动态分配，但要小心自己写的或第三方库的封装。
四、相信编译器，但别盲目相信：编译器优化选项
现代编译器（GCC/Clang）的优化能力非常强，远超一般程序员的直觉。你不需要手动把 i * 8 写成 i << 3------编译器会帮你做。
1. 常用优化级别
编译时通过 -O 选项启用优化：
| 选项 | 含义 |
|---|---|
-O0 |
默认，不做优化，方便调试 |
-O1 |
基本优化：去除无用代码、简化算术 |
-O2 |
标准优化：几乎所有的安全优化，不增加体积过大 |
-O3 |
激进优化：包含更耗编译时间的优化（如循环展开、函数内联自动判断） |
-Os |
优化体积（嵌入式常用） |
在调试阶段，我们用 -g -O0 保持代码原貌；发布时务必用 -O2 或 -O3。性能差异非常明显。
2. 被优化掉的代码
c
int x = 5;
int y = x * 10;
// 如果后面没用到 y，编译器在 -O1 下就可能完全删掉这两行当你写测试循环时，如果变量从未被读取，循环本身可能被优化掉，导致时间测量失准------这就是为什么我们用 volatile 或让变量产生输出。
3. 优化可能引入的问题
编译器优化可能改变指令顺序、消除你认为是"必须执行"的代码。依赖特定内存顺序的多线程程序，在优化下可能暴露竞态问题。这一点以后讲并发时会详细说。
总结 ：日常写代码时，把心思花在算法和数据结构上，而不是那些微小的"技巧"。把 -O2 打开，让编译器处理它擅长的部分。
五、restrict 关键字：给编译器更多信息
restrict 是 C99 引入的指针限定符 ，它告诉编译器：这个指针是访问它所指向的数据的唯一方式（没有其他指针指向同一块内存）。这能帮助编译器做更激进的优化。
典型场景：内存拷贝函数。
c
void *my_memcpy(void *restrict dest, const void *restrict src, size_t n) {
char *d = (char*)dest;
const char *s = (const char*)src;
for (size_t i = 0; i < n; i++) {
d[i] = s[i];
}
return dest;
}restrict 承诺 dest 和 src 不重叠。如果它们重叠，行为是未定义的。这个承诺让编译器可以生成更高效的汇编（比如使用 SIMD 指令一次复制多字节），而不是保守地逐字节处理。
标准库的 memcpy 就使用了 restrict，而 memmove 没有------因为 memmove 必须保证重叠区域也能正确复制。
使用条件：你确实能保证这个指针在整个生命周期中是唯一的访问路径。如果传了重叠地址，后果自负。所以只在明确不会重叠时使用。
六、inline 函数：消除函数调用开销
函数调用本身有成本：压栈、传参、跳转、返回。对于频繁调用的小函数（比如 max、min、简单的 getter），这个成本相对较大。
inline 关键字建议编译器把函数体直接展开到调用处，省去调用开销。
c
static inline int max(int a, int b) {
return (a > b) ? a : b;
}不过要注意：
inline是建议，不是命令。编译器会自行判断是否真的展开（太复杂会拒绝）。- 过度使用会导致代码体积膨胀（每处调用都复制一份），反而降低指令缓存命中率。
- 在头文件中定义
inline函数时，通常需要配合static避免多重定义。
在现代编译器中，-O2 及以上优化会自动做内联决策，手工写 inline 的意义更多是给优化器一个强烈的提示，或者用来定义必须在头文件中可用的简短函数。
七、最大的优化：选择正确的算法和数据结构
在纠结 i++ 还是 ++i 之前，先看一眼你的算法复杂度。
- 对一个百万元素的数组线性搜索，O(n)。改用哈希表或二分查找，O(log n) 甚至 O(1)，差距是天壤之别。
- 在链表中频繁按下标访问，O(n)。换成数组是 O(1)。反过来，频繁在中间插入删除，数组是 O(n)，链表是 O(1)。
算法和数据结构的选择，决定了性能上限。具体细节的优化，只是在逼近这个上限。所以，树立性能意识的第一件事，是先想清楚：我的数据结构对吗？我的算法复杂度合理吗？
八、常见误区：过早优化是万恶之源
Donald Knuth 的名言值得铭记："过早优化是万恶之源。"
初学阶段，你可能会忍不住想把所有能优化的地方都优化了------变量全用 register（现在编译器基本忽略），每个小函数都标 inline，所有除法都试图移位......但结果是代码变得晦涩难懂，而性能几乎没有提升。
建议的优先级：
- 先写正确、清晰的代码。
- 用工具找到真正的瓶颈（Profile）。
- 只在瓶颈处针对性地优化。
- 优化后再次测量，验证效果。
永远不要牺牲可读性去换取你不确定的性能收益。编译器比你更擅长微优化，而清晰的代码让你更容易发现真正的算法级优化机会。
九、小结
今天这篇文章没有教你成为性能调优大师，而是为你种下了性能意识的种子：
- 用
clock()等工具测量，别凭感觉猜。 - 空间换时间 （缓存、查表）是最常见的优化策略，时间换空间在内存紧张时可用。
- 减少不必要的
malloc/free，小对象用栈，批量分配用对象池。 - 编译时开启
-O2或-O3，让编译器替你完成微优化。 restrict和inline是优化器的高级"沟通"手段，需要明白背后的语义再使用。- 算法与数据结构的选择远比细节优化重要。
- 别让优化损害可读性，先写对，再优化。
性能优化是一个实践性很强的领域，需要在真实项目中积累经验。你现在已经有了一张"意识地图"，在之后学习更高级的数据结构、操作系统、并发编程时，这些意识会帮你做出更好的设计决策。
下一篇文章，我们将开始进入系统编程 的世界------学习如何与操作系统打交道：文件底层 I/O、系统调用、文件描述符 。那些 open、read、write 不再只是函数名，而是你程序与内核对话的接口。
课后小练习
-
写两个版本的 Fibonacci 计算函数（递归版 vs 缓存版），用
clock()计时计算fib(40)，比较两者耗时。 -
用
malloc循环分配 100 万次int并立即释放，测量耗时。再用栈数组或静态池实现同样的逻辑，比较耗时差异。 -
声明两个
restrict指针，写出一个矩阵加法函数（C = A + B），然后思考：这里能用restrict吗？为什么？（提示：C 和 A/B 重叠的情况可能吗？） -
（思考）下面的函数在
-O2优化下，空循环会被删掉吗？如果会，你如何防止它被优化，以便准确测量时间？cvoid waste_time(void) { for (int i = 0; i < 1000000; i++) { } }
我们下期见！
💡获取本系列示例代码请访问 GitCode 仓库。