工程引入了 sqlite，sqlite.c 有 23 万行
在虚拟机里面编译这个.c 要 15 分钟，裂开，make -j8 也没用
实在不行的话只能编成动态库加载了。
就是这样的话嵌入式可移植性差些，每种板子还得单独编译一个库。。。
This topic created in 2060 days ago, the information mentioned may be changed or developed.
 |
3dwelcomeMar 19, 2021 via Android
1
编译成静态库.a 文件啊。这种库又不需要每次都变得，每个平台编译一次足够了。
|
 |
lonewolfakelaMar 19, 2021
2
这个 c 文件不能拆一拆么，比如拆成七八个.c 文件，这样你的 make -j8 才能并行起来呀。
|
 |
BrettDMar 19, 2021 via iPhone
3
ccache
|
 |
fluorinedogMar 19, 2021
4
这种单体大文件没办法，不过作为库，编译一次就好，以后都有 cache
|
 |
yzwduckMar 19, 2021 via Android
5
SQLite 文档的 Amalgamation 章节讲了如何把 sqlite.c 拆成 7 个文件。
|
 |
misaka19000Mar 19, 2021
6
虚拟机？为什么不弄个性能强劲的机器来编译？
|
 |
norzMar 19, 2021
8
一楼正解...
|
 |
geekvcnMar 19, 2021
9
学 Linus，编译的使用用 3970X
|
 |
whee1Mar 19, 2021
10
-pipe 能加快一点；在 tmpfs 中进行编译。
clang 编译速度要比 gcc 要快。 |
 |
shunfyMar 19, 2021
11
嵌入个 lua 虚拟机进来,用 lua 写
|
 |
Kasumi20Mar 19, 2021
12
1 楼正解
|
 |
mingl0280Mar 19, 2021 via Android
13
文件拆分成多个.o，编译到静态库后不再经常变更。
make -j8 没用是因为这是单文件。不拆肯定单线程编译，啥 U 都不好使。你非要单线程编译建议直接 10900k （是的，这种纯吃单线程的操作只有 Intel 搞了），不过也不太好使。 |
 |
codehzMar 19, 2021 via Android
14
建议不要拆分文件，人家本来合起来就是为了让编译器做优化的，分开了性能会有影响
建议缓存对象文件 |
 |
xsenMar 20, 2021
15
除了 1 楼的建议靠谱，别的不懂就别瞎给主意
说句不好听的，把第三方库（代码量 很大那种）导入工程的话，就是脑子有坑 不仅坑自己，还坑公司 |
 |
HardrainMar 20, 2021
16
make -jN 同时 invoke 多个 cc/ld, 能加速多个源码文件同时编译,但加速不了单个(很大的)源码文件编译.
|
 |
secondwtqMar 20, 2021
17
其实这帖子整体暴露出了传统功夫 ... 传统编译器普遍具备的两个弱点，一个是并行编译和增量编译完全依赖于“文件”，另一个是 LTO 难以并行化
其实编译器实现中，编译过程最通用的结构是函数，"compilation unit"这一级别的概念并不强（更多是起一个“上下文环境”的作用），但是现在很多静态编译器还是按照绝大多数主流编程语言“文本+文件”的历史惯性，直接按照文件编译，一个文件过大直接卡整个编译过程，增量编译也是直接比较修改时间，只能说还好 Java 的优化主要靠 JIT ... LTO 就更简单粗暴了，现在大多数 LTO 就相当于帮你把代码拼一块然后优化，一个核编译几十个核围观，项目大的话可以津津有味围观好几十分钟 和编译器无关，另外一个暴露出的 C/C++ 的弱点就是自身的基础设施拉跨（按前端黑话叫“工程化”），以至于经常要靠直接拉源码的方式来引入第三方代码 ... |
 |
agagegaMar 21, 2021 via iPhone
18
这里有一个权衡：合并到同一个文件可以减少大量重复头文件处理以及文件的打开开销，但是并行性也会减少。之前 GCC 有在同一个编译单元对多个函数多线程处理的实验，要进入生产估计还要很久。
但我记得 sqlite 编译没那么慢的，四代 i5 笔记本也不至于这样。 |
Select Language