TTCN3新执行器系列-说说C++的编译速度

无意在博客园milo的blog中看到，

http://www.cnblogs.com/miloyip/archive/2010/09/17/behind_cplusplus.html
最开始的C++编译器，是将C++代码转换成C代码，使用C编译器来实现的。
这个没有具体考究，但听起来是很可信的。
因为，C++是从C发展起来的，也就是所谓的c with class，
当时C++的语言特性还是很简单的，基于语言翻译来做完全是可行且不会特复杂的。

正由此想到我们花了2年时间做的TTCN3新执行器，将高级脚本语言翻译成C++，然后基于通用的C++编译器实现。
关于为什么选择C++而非C或者JAVA，这里面有多个理由的。
譬如为了项目旧版本的组件前向兼容，项目组C++开发人员的配备，C++的抽象能力和运行性能等等。

这一切看起来都是那么的无可挑剔，但恰恰缺乏对C++编译速度的警惕。
当然，ttcn3是一种高级的脚本语言，且产品线的测试套代码量巨大（10W到20W行是正常的），
当一种高级语言映射到较低级的C++语言时，转换代码比率能控制在几倍是有很大难度的。
也就是，我们的新执行器，面对的往往是几十万级别的C++代码工程！

这个编译速度（暂不算转换速度了）大家是可以遇见的，无论是全编译还是增量编译都是一个极具挑战的任务。

于是，杯具来了，我们需要控制编译速度在二次开发人员可接受的范围内。
什么是可接受范围？
如果你面对这样动辄几十万的工程，你认为你可接受的编译时间是多少？

当然，我们承认，我们的新执行器是有很大的改进空间的，C++的编译速度也不至于那么糟糕。
但很明白的是，对比C来说，C++的速度也确实很慢的。
我们有一个基于C实现的codec编码器，对10万行的asn1操作也花不了10来秒，数据是很有说服力的。

接下来，重构的工作集中在：
1、优化代码转换比率，最大限度利用C++抽象能力，把转换代码封装到库中实现。
2、最小化模板使用。
3、最小化内联函数使用。
4、最小化文件间的依赖（类前向声明），加快增量编译时间。

于是，每一次的优化，编译性能都是有提升的，
从10个小时，到2个小时，到45分钟，到15分钟，到最后的3分钟。。。

全编译的时间能控制的比较好了，但还是解决不了增量编译时间啊。
鉴于C++是编译+链接方式的，特别对于大工程，链接的时间也比较恐怖，
随便改动个cpp文件（我已经不考虑改动h文件导致的潜在惊群编译了），链接完也得花上30秒，生成个30M的dll库。

对用户来说，30秒怎么也不像个友好的体验~

 

PS，这哥们的总结还是很到位的，具体到我的项目还是有部分不适用，但大部分都很ok！

《如何加快C++代码的编译速度的几种技巧 》

http://www.cnblogs.com/vacuum/archive/2010/03/08/1681085.html