编译源代码速度

1. 程序的编译速度与程序的执行速度

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

2. 请教，为何C程序的编译速度要比C++程序快

编译器好比一个应用程序，诸多的编译器直接自然会有速度上的差异，根据编译器功能的大小而定，一般，越大的编译器，功能越多，编译器源代码来越慢，功能简单的编译器，编译器源代码来，速度就快得多。

3. c++编程方式编写的程序源代码，为什么编译后的代码量较大,运行的速度略低

C语言是国际上广泛流行的、很有发展前途的计算机高级语言。它适合作为系统描述语言，即可用来编写系统软件，也可用来编写应用软件。正如楼上的说是一个经典。
一般情况下,c++编程方式编写的程序源代码量小,但编译后的代码量较大,运行的速度略低,不过开发时的工作量和工作难度较小;而c编程方式编写的源代码量较大,但可执行的效率高.如果一些对速度要求高,尤其是对硬件操作较多的程序,大多数还是用c编程方式开发的(用C又比用汇编简单,易于实现).另外,学Win32 C程序设计还有助于更深入地了解Windows 的内幕和Win32 API。
C语言是比较接近机器语言，它又比汇编语言更容易理解和掌握，也是比较底层的语言，正由于这些它的运行速度很快，比java,C++，VB等有更高的效率.C尤其在通信方面的作用很大，比如你想进腾讯，华为等这样大的，在通讯信息方面的公司，学C无疑是最好的，当然不是说JAVA,C++不如C好，应该各有各的长处，总之学C语言是不会过时的。当然在其他方面的 应用也很强。

4. 一个C++工程中，许多个文件都include某一个类，当该类更新时，编译速度太慢，怎么办

这是个好问题，虽然老生常谈，但真正知道解决方案的人很少。《EffectiveC++》有介绍，同时推荐这本书给所有C++er。
一个组织有问题的大型项目中，影响编译速度的最大问题就是头文件形成庞大的依赖网络，其中一个头文件修改就导致一大堆间接依赖的源代码文件需要重新编译。a.h包含b.h，b.h包含c.h，c.h又包含d.h，即使a.h和d.h似乎没什么关系，修改d.h的时候还是无可避免a.cc被重新编译。
首先得知道C++一个特性，函数分为声明和实现两部分是人所皆知，但类也可以分为前置声明和定义可能知道的人就比较少了，知道能怎么用就更少了，其实就是可以用来解决编译速度问题的。

5. 编译后的程序比边解释边执行的程序的运行速度快吗为什么

程序的编译是指将人可以理解的代码(如C的源代码)段编译成机器指令码（二级制指令），也就是处理堆栈、处理器、总线的指令，交由计算机自动执行。解释型语言是在需要执行时临时编译运行，执行时多了编译的过程，自然就要慢的多了。
比较特殊的是java,javac命令编译的结果虽然也是二进制文件，但实际也不是机器指令，而是优化后的代码，最后的执行是通过java虚拟机再次编译后执行。所以效率介于编译型和解释型之间。
目前java的执行速度已经有了大幅度的提升，但要想赶上或超越C 或者汇编，理论上是不现实的。

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

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

7. 浅谈怎样加快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++中两种比较“先进”的机制，但是它们却又强制我们在头文件中包含实现，这对增加头文件的内容，从而减慢编译速度有着很大的贡献。使用之前，权衡一下。

8. 如何提高pb9编译程序速度

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

9. 如何提高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