V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
auto8888
V2EX  ›  C++

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

  •  
  •   auto8888 · 2021-03-19 14:45:57 +08:00 · 3443 次点击
    这是一个创建于 1371 天前的主题,其中的信息可能已经有所发展或是发生改变。

    工程引入了 sqlite,sqlite.c 有 23 万行

    在虚拟机里面编译这个.c 要 15 分钟,裂开,make -j8 也没用

    实在不行的话只能编成动态库加载了。

    就是这样的话嵌入式可移植性差些,每种板子还得单独编译一个库。。。

    18 条回复    2021-03-21 10:34:12 +08:00
    3dwelcome
        1
    3dwelcome  
       2021-03-19 14:49:52 +08:00 via Android
    编译成静态库.a 文件啊。这种库又不需要每次都变得,每个平台编译一次足够了。
    lonewolfakela
        2
    lonewolfakela  
       2021-03-19 14:54:11 +08:00
    这个 c 文件不能拆一拆么,比如拆成七八个.c 文件,这样你的 make -j8 才能并行起来呀。
    BrettD
        3
    BrettD  
       2021-03-19 14:56:07 +08:00 via iPhone
    ccache
    fluorinedog
        4
    fluorinedog  
       2021-03-19 14:57:26 +08:00
    这种单体大文件没办法,不过作为库,编译一次就好,以后都有 cache
    yzwduck
        5
    yzwduck  
       2021-03-19 15:18:45 +08:00 via Android
    SQLite 文档的 Amalgamation 章节讲了如何把 sqlite.c 拆成 7 个文件。
    misaka19000
        6
    misaka19000  
       2021-03-19 15:22:01 +08:00
    虚拟机?为什么不弄个性能强劲的机器来编译?
    bruce0
        7
    bruce0  
       2021-03-19 16:04:56 +08:00
    @3dwelcome 我觉得一楼说的有道理
    norz
        8
    norz  
       2021-03-19 16:16:46 +08:00
    一楼正解...
    geekvcn
        9
    geekvcn  
       2021-03-19 16:22:48 +08:00
    学 Linus,编译的使用用 3970X
    whee1
        10
    whee1  
       2021-03-19 16:24:13 +08:00
    -pipe 能加快一点;在 tmpfs 中进行编译。
    clang 编译速度要比 gcc 要快。
    shunfy
        11
    shunfy  
       2021-03-19 16:55:13 +08:00
    嵌入个 lua 虚拟机进来,用 lua 写
    Kasumi20
        12
    Kasumi20  
       2021-03-19 16:58:14 +08:00
    1 楼正解
    mingl0280
        13
    mingl0280  
       2021-03-19 17:21:38 +08:00 via Android
    文件拆分成多个.o,编译到静态库后不再经常变更。
    make -j8 没用是因为这是单文件。不拆肯定单线程编译,啥 U 都不好使。你非要单线程编译建议直接 10900k (是的,这种纯吃单线程的操作只有 Intel 搞了),不过也不太好使。
    codehz
        14
    codehz  
       2021-03-19 21:34:06 +08:00 via Android
    建议不要拆分文件,人家本来合起来就是为了让编译器做优化的,分开了性能会有影响
    建议缓存对象文件
    xsen
        15
    xsen  
       2021-03-20 08:44:06 +08:00
    除了 1 楼的建议靠谱,别的不懂就别瞎给主意

    说句不好听的,把第三方库(代码量 很大那种)导入工程的话,就是脑子有坑
    不仅坑自己,还坑公司
    Hardrain
        16
    Hardrain  
       2021-03-20 17:07:54 +08:00
    make -jN 同时 invoke 多个 cc/ld, 能加速多个源码文件同时编译,但加速不了单个(很大的)源码文件编译.
    secondwtq
        17
    secondwtq  
       2021-03-20 18:28:48 +08:00
    其实这帖子整体暴露出了传统功夫 ... 传统编译器普遍具备的两个弱点,一个是并行编译和增量编译完全依赖于“文件”,另一个是 LTO 难以并行化
    其实编译器实现中,编译过程最通用的结构是函数,"compilation unit"这一级别的概念并不强(更多是起一个“上下文环境”的作用),但是现在很多静态编译器还是按照绝大多数主流编程语言“文本+文件”的历史惯性,直接按照文件编译,一个文件过大直接卡整个编译过程,增量编译也是直接比较修改时间,只能说还好 Java 的优化主要靠 JIT ...
    LTO 就更简单粗暴了,现在大多数 LTO 就相当于帮你把代码拼一块然后优化,一个核编译几十个核围观,项目大的话可以津津有味围观好几十分钟

    和编译器无关,另外一个暴露出的 C/C++ 的弱点就是自身的基础设施拉跨(按前端黑话叫“工程化”),以至于经常要靠直接拉源码的方式来引入第三方代码 ...
    agagega
        18
    agagega  
       2021-03-21 10:34:12 +08:00 via iPhone
    这里有一个权衡:合并到同一个文件可以减少大量重复头文件处理以及文件的打开开销,但是并行性也会减少。之前 GCC 有在同一个编译单元对多个函数多线程处理的实验,要进入生产估计还要很久。

    但我记得 sqlite 编译没那么慢的,四代 i5 笔记本也不至于这样。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5336 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 26ms · UTC 07:02 · PVG 15:02 · LAX 23:02 · JFK 02:02
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.