源代码行数多时如何提高编译速度？

编译成静态库.a 文件啊。这种库又不需要每次都变得，每个平台编译一次足够了。

这个 c 文件不能拆一拆么，比如拆成七八个.c 文件，这样你的 make -j8 才能并行起来呀。

ccache

这种单体大文件没办法，不过作为库，编译一次就好，以后都有 cache

SQLite 文档的 Amalgamation 章节讲了如何把 sqlite.c 拆成 7 个文件。

虚拟机？为什么不弄个性能强劲的机器来编译？

@3dwelcome 我觉得一楼说的有道理

一楼正解...

学 Linus，编译的使用用 3970X

-pipe 能加快一点；在 tmpfs 中进行编译。
clang 编译速度要比 gcc 要快。

嵌入个 lua 虚拟机进来,用 lua 写

1 楼正解

文件拆分成多个.o，编译到静态库后不再经常变更。
make -j8 没用是因为这是单文件。不拆肯定单线程编译，啥 U 都不好使。你非要单线程编译建议直接 10900k （是的，这种纯吃单线程的操作只有 Intel 搞了），不过也不太好使。

建议不要拆分文件，人家本来合起来就是为了让编译器做优化的，分开了性能会有影响
建议缓存对象文件

除了 1 楼的建议靠谱，别的不懂就别瞎给主意

说句不好听的，把第三方库（代码量 很大那种）导入工程的话，就是脑子有坑
不仅坑自己，还坑公司

make -jN 同时 invoke 多个 cc/ld, 能加速多个源码文件同时编译,但加速不了单个(很大的)源码文件编译.

其实这帖子整体暴露出了传统功夫 ... 传统编译器普遍具备的两个弱点，一个是并行编译和增量编译完全依赖于“文件”，另一个是 LTO 难以并行化
其实编译器实现中，编译过程最通用的结构是函数，"compilation unit"这一级别的概念并不强（更多是起一个“上下文环境”的作用），但是现在很多静态编译器还是按照绝大多数主流编程语言“文本+文件”的历史惯性，直接按照文件编译，一个文件过大直接卡整个编译过程，增量编译也是直接比较修改时间，只能说还好 Java 的优化主要靠 JIT ...
LTO 就更简单粗暴了，现在大多数 LTO 就相当于帮你把代码拼一块然后优化，一个核编译几十个核围观，项目大的话可以津津有味围观好几十分钟

和编译器无关，另外一个暴露出的 C/C++ 的弱点就是自身的基础设施拉跨（按前端黑话叫“工程化”），以至于经常要靠直接拉源码的方式来引入第三方代码 ...

这里有一个权衡：合并到同一个文件可以减少大量重复头文件处理以及文件的打开开销，但是并行性也会减少。之前 GCC 有在同一个编译单元对多个函数多线程处理的实验，要进入生产估计还要很久。

但我记得 sqlite 编译没那么慢的，四代 i5 笔记本也不至于这样。