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

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

  •  
  •   auto8888 · 308 天前 · 2012 次点击
    这是一个创建于 308 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

    但我记得 sqlite 编译没那么慢的,四代 i5 笔记本也不至于这样。
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1354 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 00:08 · PVG 08:08 · LAX 16:08 · JFK 19:08
    ♥ Do have faith in what you're doing.