编译速度

① 浅谈怎样加快C++代码的编译速度

C++代码一直以其运行时的高性能高调面对世人， 但是说起编译速度，却只有低调的份了。比如我现在工作的源代码，哪怕使用Incredibuild调动近百台机子，一个完整的build也需要四个小时，恐怖！！！虽然平时开发一般不需要在本地做完整的build，但编译几个相关的工程就够你等上好一段时间的了（老外管这个叫monkey around，相当形象）。想想若干年在一台单核2.8GHZ上工作时的场景 - 面前放本书，一点build按钮，就低头读一会书~~~往事不堪回首。 可以想象，如果不加以重视，编译速度极有可能会成为开发过程中的一个瓶颈。那么，为什么C++它就编译的这么慢呢？ 我想最重要的一个原因应该是C++基本的“头文件-源文件”的编译模型： 1.每个源文件作为一个编译单元，可能会包含上百甚至上千个头文件，而在每一个编译单元，这些头文件都会被从硬盘读进来一遍，然后被解析一遍。 2.每个编译单元都会产生一个obj文件，然后所以这些obj文件会被link到一起，并且这个过程很难并行。 这里，问题在于无数头文件的重复load与解析，以及密集的磁盘操作。 下面从各个角度给出一些加快编译速度的做法，主要还是针对上面提出的这个关键问题。 一、代码角度 1、在头文件中使用前置声明，而不是直接包含头文件。 不要以为你只是多加了一个头文件，由于头文件的“被包含”特性，这种效果可能会被无限放大。所以，要尽一切可能使头文件精简。很多时候前置申明某个namespace中的类会比较痛苦，而直接include会方便很多，千万要抵制住这种诱惑；类的成员，函数参数等也尽量用引用，指针，为前置声明创造条件。 2、使用Pimpl模式 Pimpl全称为Private Implementation。传统的C++的类的接口与实现是混淆在一起的，而Pimpl这种做法使得类的接口与实现得以完全分离。如此，只要类的公共接口保持不变，对类实现的修改始终只需编译该cpp；同时，该类提供给外界的头文件也会精简许多。 3、高度模块化 模块化就是低耦合，就是尽可能的减少相互依赖。这里其实有两个层面的意思。一是文件与文件之间，一个头文件的变化，尽量不要引起其他文件的重新编译；二是工程与工程之间，对一个工程的修改，尽量不要引起太多其他工程的编译。这就要求头文件，或者工程的内容一定要单一，不要什么东西都往里面塞，从而引起不必要的依赖。这也可以说是内聚性吧。 以头文件为例，不要把两个不相关的类，或者没什么联系的宏定义放到一个头文件里。内容要尽量单一，从而不会使包含他们的文件包含了不需要的内容。记得我们曾经做过这么一个事，把代码中最“hot”的那些头文件找出来，然后分成多个独立的小文件，效果相当可观。 其实我们去年做过的refactoring，把众多DLL分离成UI与Core两个部分，也是有着相同的效果的 - 提高开发效率。 4、删除冗余的头文件 一些代码经过上十年的开发与维护，经手的人无数，很有可能出现包含了没用的头文件，或重复包含的现象，去掉这些冗余的include是相当必要的。当然，这主要是针对cpp的，因为对于一个头文件，其中的某个include是否冗余很难界定，得看是否在最终的编译单元中用到了，而这样又可能出现在一个编译单元用到了，而在另外一个编译单元中没用到的情况。 之前曾写过一个Perl脚本用来自动去除这些冗余的头文件，在某个工程中竟然去掉多达了5000多个的include。 5、特别注意inline和template 这是C++中两种比较“先进”的机制，但是它们却又强制我们在头文件中包含实现，这对增加头文件的内容，从而减慢编译速度有着很大的贡献。使用之前，权衡一下。

② 如何加快C++代码的编译速度

最重要的一个原因应该是C++基本的"头文件-源文件"的编译模型：
每个源文件作为一个编译单元，可能会包含上百甚至上千个头文件，而在每一个编译单元，这些头文件都会被从硬盘读进来一遍，然后被解析一遍。
每个编译单元都会产生一个obj文件，然后所以这些obj文件会被link到一起，并且这个过程很难并行。
这里，问题在于无数头文件的重复load与解析，以及密集的磁盘操作。

③ c语言的编译效率是最快的吗

计算机不能直接理解高级语言，只能直接理解机器语言，所以必须要把高级语言翻译成机器语言，计算机才能执行高级语言编写的程序。翻译的方式有两种，一个是编译，一个是解释。两种方式只是翻译的时间不同。编译型语言写的程序执行之前，需要一个专门的编译过程，把程序编译成为机器语言的文件，比如exe文件，以后要运行的话就不用重新翻译了，直接使用编译的结果就行了（exe文件），因为翻译只做了一次，运行时不需要翻译，所以编译型语言的程序执行效率高，但也不能一概而论，部分解释型语言的解释器通过在运行时动态优化代码，甚至能够使解释型语言的性能超过编译型语言。解释则不同，解释性语言的程序不需要编译，省了道工序，解释性语言在运行程序的时候才翻译，比如解释性basic语言，专门有一个解释器能够直接执行basic程序，每个语句都是执行的时候才翻译。这样解释性语言每执行一次就要翻译一次，效率比较低。解释是一句一句的翻译。编译型与解释型，两者各有利弊。前者由于程序执行速度快，同等条件下对系统要求较低，因此像开发操作系统、大型应用程序、数据库系统等时都采用它，像C/C++、Pascal/Object Pascal（Delphi）等都是编译语言，而一些网页脚本、服务器脚本及辅助开发接口这样的对速度要求不高、对不同系统平台间的兼容性有一定要求的程序则通常使用解释性语言，如Java、JavaScript、VBScript、Perl、Python、Ruby、MATLAB 等等。但随着硬件的升级和设计思想的变革，编译型和解释型语言越来越笼统，主要体现在一些新兴的高级语言上，而解释型语言的自身特点也使得编译器厂商愿意花费更多成本来优化解释器，解释型语言性能超过编译型语言也是必然的。

④ 如何提高vs2010编译速度

如果你的cpu够强你应该学会如何利用好它来加速你的代码编译速度，那么你怎么才能够最大限度让你的cpu发烧呢？

下面是一个对比：

比如我的cpu是i7 3770k，

编译cocos2d-x的libcocos2d工程：

不优化：

1>Time Elapsed 00:01:35.25

优化后：

1>Time Elapsed 00:00:21.66

效果显着！！！

参考网页：

Visual Studio 2010中C++并行构建调优(1)
http://developer.51cto.com/art/201003/189235.htm

1>cl : Command line warning D9030: '/Gm' is incompatible with multiprocessing; ignoring /MP switch

解决办法是：

Properties -> Configuration Properties -> C/C++ -> Code Generation -> Enable Minimal Rebuild -> No(/Gm-)

Properties -> Configuration Properties -> C/C++ -> Geneal -> Multi-processor Compilation -> Yes(/MP)

一些含义和拓展资料：

Enable minimal rebuild
通过保存关联信息到.IDB文件，使编译器只对最新类定义改动过的源文件进行重编译，提高编译速度

Enable Incremental Compilation
同样通过.IDB文件保存的信息，只重编译最新改动过的函数

/MP (Build with Multiple Processes)

http://msdn.microsoft.com/en-us/library/bb385193.aspx

/Gm (Enable Minimal Rebuild)

http://msdn.microsoft.com/en-us/library/kfz8ad09.aspx

⑤ android studio 编译怎么提高编译速度

方法：
1.开启gradle单独的守护进程
在下面的目录下面创建gradle.properties文件：
/home/<username>/.gradle/ (Linux)
/Users/<username>/.gradle/ (Mac)
C:\Users\<username>\.gradle (Windows)
并在文件中增加： org.gradle.daemon=true
同时修改项目下的gradle.properties文件也可以优化。
2.修改android studio配置，在android studio的配置中，开启offline模式，以及修改配置。实际上的配置和上面的一大段一样，主要是在这个地方配置的只会在ide构建的时候生效，命令行构建不会生效。

⑥ 如何提高大型工程的编译速度

影响因素比较多：1文件的大小，文件大小指的是全部include后的大校2文件数量，编译是一个一个文件进行的，所以你的工程的文件数量也有关系。3还有声明的复杂程度，复杂声明需要额外地计算。4最影响编译速度的估计是C++的模板

⑦ 编译一段代码的速度和CPU的线程核心和代码的速度有关吗如果编译一个QQ大小的代码需要多长时间啊

1cpu的速度跟核心数量有关吗?是否数量越多就越快呢？只有在同一家族的CPU中进行比较，核心数量、主频与CPU的运行速度才有正比关系，还有影响的因素是2、3级缓存的大小。核心版本和工艺的升级也有影响。一般在同一家族的CPU中，核心越多、主频越高、缓存越多、版本越新的CPU越快。比如AMDAthlonIIX2250肯定要比AMDAthlonIIX2240要快，但是不是也一定强于主频、缓存、核心数都与X2240差不多的IntelPentiumE6300呢？那就不能武断的说了。需要用各种测试软件去验证。2同核心数目，同主频，同二级缓存哪个快？主板配cpu是看针脚和前端总线,和cpu的二级缓存无关,865的主板如果是478接口的,那就支持P42.8E和P43.2C,何况主板和cpu前端总线都是800mhz,完美支持两个比当然是P43.2C好了,虽然P42.8e是1024的二级缓存,但核心是Prescott内核,和A的核心一样,发热量大,功耗高,而C的核心是NORTHWOOD核心,比Prescott好

⑧ 程序的编译速度与程序的执行速度

执行与编译。。也有挂钩！。。执行、编译速度又跟硬件有关！用 WEB来说 第一次编译比较慢！后面这次访问就快多了！这跟缓存有关。。还有就是代码的问题。。 多次的循环判断也会造成系统执行变慢！。。在提升速度方面 主要就是俩种方法 1.完善的代码 2.提高硬件了！可能我说的比较片面！别的兄弟可以继续补充！

⑨ 如何提高android.mk的编译速度

从eclipse转到Android studio,总觉得编译速度或者安装到手机上的速度会变很快,现实是仍然很慢,所以就搜如何提高build速度,安装真机上apk能快一点,步骤如下:
1.修改android studio的使用堆内存,根据自己电脑的内存,尽量设置的大一点,点击help->如下图:
2.接下来设置使用离线gradle构建,一开始就是使用了内置的默认路径gradle,勾选offline这个选项,编译的速度快的不止一点点,在.gradle的离线位置,建立一个gradle.properties的文件,设置精灵后台一直编译,这样提高了很多的速度

⑩ 影响vs编译速度的因素有哪些

影响因素比较多：
1 文件的大小，文件大小指的是全部include展开后的大小。
2 文件数量，编译是一个一个文件进行的，所以你的工程的文件数量也有关系。
3 还有声明的复杂程度，复杂声明需要额外地计算。
4 最影响编译速度的估计是C++的模板，模板在编译的时候要进行推导，得到相应的结果，这个非常费时间。如果你是模板里还套了模板，那就比较慢了。
5 链接库的数量，链接很多库也会使得编译速度变慢。
6 inline函数展开，会使得代码膨胀，也会影响编译速度
7 debug模式编译要留符号表做调试，也会影响速度
8 release模式如果开了优化，编译优化会改变代码的某些结构，这也是拖慢编译器的一个重要因素。