Precompiled Header和Incredibuild的恩怨

 

    5年以前，做过一个xbox 360游戏，当时整个开发团队在pc上做各种开发，我一个人做前期的PC->360移植，这是很大的一个游戏，由于之前很多年开发都没体会到预编译头文件的威力，所以移植的时候偷懒，没有设置预编译头文件的选项（precompiled header,简称PCH)。其实每个solution里面的项目只要几分钟就可以设置好了，但我偏偏没有做。 
    移植的话，第一步也是最重要的一步是，试图让所有的代码编译通过，并能load地图，跑起main loop。（原因并不复杂，以后会在别的文章里面细谈）随着新项目和新代码逐步加入，编译时间越来越长，当我逐步把大量projects加到了solution以后，完整编译一次的时间上升到一个半小时，而且看趋势还会更多。偏偏unreal引擎把很多script object的meta info全放进了头文件（就是那些*classes.h)，我那段时间经常在改script，被迫频频完整重编译，一天上班，上午重编译2次，下午2次，基本就可以回家了。。。 
    忘了那时候是怎么开窍的，想起了预编译头文件，查了一下文档，似乎能极大地加速编译时间。于是做了些尝试，试着改了一个project，发现果然快了很多，于是全部改掉，结果发现整个游戏的编译时间缩短到半个多小时。期间还遇到xbox 360 sdk的预编译头文件bug，用了些奇怪的解决方法。 
    从此我开始特别留心预编译头文件的选项，也在不少项目中改进他们的设置，加入预编译头文件以便加快编译速度，屡试不爽，直到上个月。。。 
    那是一个挺小的项目，和之前的项目比，编译时间不算太长，10分钟就能完成全部编译，但是能提高编译速度总是有价值的。我发现项目里面居然没有设置预编译头文件，于是摩拳擦掌开始干活了。 
    开工前我先测量了一下优化前的编译速度，找了solution里面三个规模适中的项目开刀，统计了一下编译速度，然后设置好预编译头文件选项，再测一次，不出所料，提高不小： 
Laptop, 5400RPM HD, Intel P7500, without/with PCH, compiling time: 
    Proj 1: 30s -> 15s 
    Proj 2: 5m57s -> 3m35s 
    Proj 3: 3m15s -> 1m1s 
    我自信满满地check in新项目，跑到别人那里去测，居然发现在别人那里设置预编译头之后反而更慢了。。。有没有搞错啊。。。后来怀疑到Incredibuild上面，Incredibuild是一个分布式编译的工具，可以用多台电脑进行网络协同编译，同事的有些机器上用，有些机器没有用。但凡是用Incredibuild的，编译速度很有可能比不用预编译头的时候慢，但也不是100%，不用的话一定是用预编译头文件的快很多。于是试图在自己的台式电脑上重现，并仔细测量各种设置下的编译速度得到如下数据： 
Desktop, 7200RPM HD, AMD Phenon 9550, with PCH, with/without Incredibuild 
    Proj 4: 24s -> 11s 
    Proj 5: 27s -> 8s 
    Proj 6: 4m51 -> 42s 
    Proj 7: 27s -> 20s 
    在这台机器上似乎没有重现问题，只要设置了PCH，不管是否使用Incredibuild，速度一定会比原来快很多。于是进一步找原因，google，乱猜。后来发现如果把这台四核的机器的VC设置改变一下，编译时只用1个核的话，就会出现有PCH选项的编译速度反而慢于不用PCH的编译。 
    上网查了一下，发现Incredibuild官网上提过，Precompiled header会影响效果，原因是如果PCH太大，很多时候其他网络机器都在等PCH文件的传输，然后才能开始一起编译。顺着这个思路，经过多次试验和总结，得出以下结论： 
    预编译头文件对单独机器的编译，是有价值的，在几台低端机上面试验，提高编译速度从50%-3倍不等 
    然而，使用incredibuild和PCH的情况下 
        1. 大尺寸的PCH需要在网络上传输很久 传完以后其他机器才可以帮助一起编译 
            1.1 如果项目够大，那使用PCH还是有帮助的，因为等待PCH传输的时间会在以后的协同编译中省回来 
            1.3 如果不够大，又分为几种情况： 
                1.3.1 对于本地编译能力够强的机器来说，仍然是使用PCH有好处（我用一台4核来编译的） 
                    因为后期本机能处理大量的编译任务，对网络联合编译依赖较小，虽然并发编译的开始时间慢了，但是本机4核从中得到的好处远大于网络编译，往往是网络其他机器刚开始帮忙，整个项目已经差不多编译完了。 
                1.3.2 如果本地机器一般（在一台AMD双核上面），那么可能用不用PCH速度差不多 
                1.3.3 对于低端机，主要依赖网络联合编译的，用PCH会慢，因为PCH推迟了并发编译开始的时间 
        2. 小尺寸的PCH，取得一个折中，可在高低端机器上都有比较理想的表现。 
            我手动把不少头文件从PCH里面拆出来，发现低端机用Incredibuild编译速度果然能快不少，但是高端机又下来了。。。只好凭感觉调了个差不多大家都能接受的值出来。

    经此一事，我更加觉得，Incredibuild不是一个非常理想的工具，虽然看上去很美，原因如下： 
        前公司也用过，效果一般，可能因为以前公司机器都比较好，符合我上面说的情况1.3.1，所以大家都不爱用 
        Incredibuild的license狂贵，有这点钱，还不如买台I7，对这类小项目，绝对比Incrediblebuild有用 
        最致命的一点： 
            实际开发中，大规模的重编译是不多的，一般只发生在： 
                Sync最新版本 
                调整项目设置 
                移植/升级sdk/做大功能以后的整合/branch版本的merge等等 
            而上述这些情况，发生的机会不是特别多，每个开发人员日常工作中，90%以上的时间，是改几行代码，然后编译。在这个情况下，link会占用多数的时间，（以前做的360游戏link超过5分钟，PS3游戏link超过15分钟，PC上超过10分钟的也有，当然和我们项目组织不理想也有一定的关系），而link时间，恰恰是Incredibuild无能为力的领域。 
    随着机器多核化，我想，Incredibuild这类辅助编译的工具会有麻烦的。

转载于:https://www.cnblogs.com/gamedev/archive/2012/07/31/2616289.html