① 如何加快C++代码的编译速度
最重要的一个原因应该是C++基本的"头文件-源文件"的编译模型：
每个源文件作为一个编译单元，可能会包含上百甚至上千个头文件，而在每一个编译单元，这些头文件都会被从硬盘读进来一遍，然后被解析一遍。
每个编译单元都会产生一个obj文件，然后所以这些obj文件会被link到一起，并且这个过程很难并行。
这里，问题在于无数头文件的重复load与解析，以及密集的磁盘操作。
② 程序的编译速度与程序的执行速度
执行与编译。。也有挂钩！。。执行、编译速度又跟硬件有关！用 WEB来说 第一次编译比较慢！后面这次访问就快多了！这跟缓存有关。。还有就是代码的问题。。 多次的循环判断也会造成系统执行变慢！。。在提升速度方面 主要就是俩种方法 1.完善的代码 2.提高硬件了！可能我说的比较片面！别的兄弟可以继续补充！
③ 在Win7下安装了CTeX学习LaTex，那编译速度，真叫一个慢，要一分钟才能编译完！再看看linux下的，真快！
图形界面本身是个拖累，然后微软自己的库比较庞杂臃肿
还有LaTex本来就是类Unix机上开发起家的，linux当然更亲切些
④ 如何提高Keil4的编译速度
没有必要提高Keil4的编译速度，短小程序的编译也就是点下鼠标的功夫就完成了。
稍长一些程序，编译也不过几秒的事。也不是需要几十分钟，想提高速度。
如果程序真的很长，编译就需要一点时间的，这提高不了速度。要提高速度，只能在写程序时，尽量优化吧。
如果你的电脑编译的时间很长的话，还是查一个系统的问题吧。
⑤ c语言的编译效率是最快的吗
计算机不能直接理解高级语言，只能直接理解机器语言，所以必须要把高级语言翻译成机器语言，计算机才能执行高级语言编写的程序。翻译的方式有两种，一个是编译，一个是解释。两种方式只是翻译的时间不同。编译型语言写的程序执行之前，需要一个专门的编译过程，把程序编译成为机器语言的文件，比如exe文件，以后要运行的话就不用重新翻译了，直接使用编译的结果就行了（exe文件），因为翻译只做了一次，运行时不需要翻译，所以编译型语言的程序执行效率高，但也不能一概而论，部分解释型语言的解释器通过在运行时动态优化代码，甚至能够使解释型语言的性能超过编译型语言。解释则不同，解释性语言的程序不需要编译，省了道工序，解释性语言在运行程序的时候才翻译，比如解释性basic语言，专门有一个解释器能够直接执行basic程序，每个语句都是执行的时候才翻译。这样解释性语言每执行一次就要翻译一次，效率比较低。解释是一句一句的翻译。编译型与解释型，两者各有利弊。前者由于程序执行速度快，同等条件下对系统要求较低，因此像开发操作系统、大型应用程序、数据库系统等时都采用它，像C/C++、Pascal/Object Pascal（Delphi）等都是编译语言，而一些网页脚本、服务器脚本及辅助开发接口这样的对速度要求不高、对不同系统平台间的兼容性有一定要求的程序则通常使用解释性语言，如Java、JavaScript、VBScript、Perl、Python、Ruby、MATLAB 等等。但随着硬件的升级和设计思想的变革，编译型和解释型语言越来越笼统，主要体现在一些新兴的高级语言上，而解释型语言的自身特点也使得编译器厂商愿意花费更多成本来优化解释器，解释型语言性能超过编译型语言也是必然的。
⑥ 浅谈怎样加快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++中两种比较“先进”的机制，但是它们却又强制我们在头文件中包含实现，这对增加头文件的内容，从而减慢编译速度有着很大的贡献。使用之前，权衡一下。
⑦ 为什么Visual Studio 2010的编译速度比Visual Studio 6.0慢很多，有什么方法可以加快速度吗
编译器不同，使用的编译方法不同，主要差异在代码优化，智能纠错等方面。6.0是上世纪的产物，连C++标准都实现的非常不完善，更何况代码优化之类的特别费时的工作。随着CPU和操作系统技术的发展，二进制代码生成更加困难，优化更加复杂，当然最终代码的执行效率会更高。
另一方面也是由于nt内核的代码复杂度变的更高，vs2010的头文件和6.0的版本是不同的，很多新的的系统特性都被加入到windows头文件中。
加快速度的方法有禁用优化选项，禁用clr检查等。最基本的还是良好的程序结构，能减少编译器的工作量。vs在生成代码的时候即使是release模式仍然会创建大量的调试信息在工程中，以帮助问题发现和恢复，在vc6时代是没有这东西的。
⑧ 如何解决android studio运行编译速度慢
方法很多：
暴力：
换电脑，高配置，撸起。
温和：
修改xmx配置参数http://blog.csdn.net/xyxjn/article/details/46906909
减少不必要的内存消耗，加快编译速度。
灵活：
使用第三方插件进行快速编译 ，例如阿里集团的 freeline这种编译插件。
⑨ 影响vs编译速度的因素有哪些
影响因素比较多：
1 文件的大小，文件大小指的是全部include展开后的大小。
2 文件数量，编译是一个一个文件进行的，所以你的工程的文件数量也有关系。
3 还有声明的复杂程度，复杂声明需要额外地计算。
4 最影响编译速度的估计是C++的模板，模板在编译的时候要进行推导，得到相应的结果，这个非常费时间。如果你是模板里还套了模板，那就比较慢了。
5 链接库的数量，链接很多库也会使得编译速度变慢。
6 inline函数展开，会使得代码膨胀，也会影响编译速度
7 debug模式编译要留符号表做调试，也会影响速度
8 release模式如果开了优化，编译优化会改变代码的某些结构，这也是拖慢编译器的一个重要因素。