一些原因是:

1) c++语法比c#或Java更复杂，需要更多的时间来解析。

2)(更重要的是)c++编译器生成机器代码，并在编译期间进行所有优化。c#和Java只走了一半，将这些步骤留给JIT。

解析和代码生成实际上相当快。真正的问题是打开和关闭文件。记住，即使使用include守卫，编译器仍然打开. h文件，读取每一行(然后忽略它)。

有一次，我的一个朋友(在工作无聊的时候)把他公司的应用程序——所有的源文件和头文件——放到一个大文件中。编译时间从3小时下降到7分钟。

编译语言总是比解释语言需要更大的初始开销。此外，也许您没有很好地组织您的c++代码。例如:

#include "BigClass.h"

class SmallClass
{
   BigClass m_bigClass;
}

编译速度比:

class BigClass;

class SmallClass
{
   BigClass* m_bigClass;
}

另一个原因是使用C预处理器来定位声明。即使使用了头保护，.h仍然必须在每次包含它们时被反复解析。一些编译器支持预编译的头文件，可以帮助解决这个问题，但它们并不总是被使用。

参见:c++常见问题答案

Most answers are being a bit unclear in mentioning that C# will always run slower due to the cost of performing actions that in C++ are performed only once at compile time, this performance cost is also impacted due runtime dependencies (more things to load to be able to run), not to mention that C# programs will always have higher memory footprint, all resulting in performance being more closely related to the capability of hardware available. The same is true to other languages that are interpreted or depend on a VM.

最大的问题是:

1)无限头解析。已经提到过。缓解(如#pragma once)通常只适用于每个编译单元，而不是每个构建。

2)事实上，工具链经常被分离成多个二进制文件(make、预处理器、编译器、汇编器、归档器、impdef、链接器和dll工具)，这些二进制文件必须在每次调用(编译器、汇编器)或每一对文件(归档器、链接器和dll工具)时重新初始化和重新加载所有状态。

请参见关于comp.compilers: http://compilers.iecc.com/comparch/article/03-11-078的讨论，特别是这个:

http://compilers.iecc.com/comparch/article/02-07-128

请注意，comp.compilers的主持人John似乎也同意这一点，这意味着如果完全集成工具链并实现预编译的头文件，那么C语言也应该可以达到类似的速度。许多商业C编译器在某种程度上都这样做。

请注意，Unix将所有内容分解为单独的二进制文件的模型对于Windows来说是一种最坏的情况模型(其进程创建缓慢)。在比较Windows和*nix之间的GCC构建时间时，这是非常明显的，特别是当make/configure系统还调用一些程序只是为了获取信息时。