任何编译器的减速都不一定相同。

我没有使用过Delphi或Kylix，但在MS-DOS时代，Turbo Pascal程序几乎可以立即编译，而等效的Turbo c++程序只能爬行。

两个主要的区别是一个非常强大的模块系统和允许单次编译的语法。

编译速度当然可能不是c++编译器开发人员的优先考虑事项，但C/ c++语法中也有一些固有的复杂性，这使得处理起来更加困难。(我不是C方面的专家，但Walter Bright是，在构建了各种商业C/ c++编译器之后，他创建了D语言。他的改变之一是强制使用上下文无关的语法，使语言更容易解析。)

此外，您还会注意到，makefile通常设置为每个文件都单独用C编译，因此如果10个源文件都使用相同的包含文件，则该包含文件将被处理10次。

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) c++语法比c#或Java更复杂，需要更多的时间来解析。

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

c++被编译成机器代码。所以你有预处理器，编译器，优化器，最后是汇编器，所有这些都必须运行。

Java和c#被编译成字节码/IL, Java虚拟机/。NET框架执行(或JIT编译成机器代码)之前执行。

Python是一种解释型语言，它也被编译成字节码。

我相信还有其他原因，但总的来说，不需要编译为本机机器语言可以节省时间。

任何编译器的减速都不一定相同。

我没有使用过Delphi或Kylix，但在MS-DOS时代，Turbo Pascal程序几乎可以立即编译，而等效的Turbo c++程序只能爬行。

两个主要的区别是一个非常强大的模块系统和允许单次编译的语法。

编译速度当然可能不是c++编译器开发人员的优先考虑事项，但C/ c++语法中也有一些固有的复杂性，这使得处理起来更加困难。(我不是C方面的专家，但Walter Bright是，在构建了各种商业C/ c++编译器之后，他创建了D语言。他的改变之一是强制使用上下文无关的语法，使语言更容易解析。)

此外，您还会注意到，makefile通常设置为每个文件都单独用C编译，因此如果10个源文件都使用相同的包含文件，则该包含文件将被处理10次。

简单地回答这个问题，c++是一种比市场上其他可用语言复杂得多的语言。它有一个遗留的包含模型，可以多次解析代码，并且它的模板库没有针对编译速度进行优化。

语法和ADL

让我们通过一个非常简单的例子来看看c++的语法复杂性:

x*y;

虽然你可能会说上面是一个带有乘法的表达式，但在c++中不一定是这样。如果x是一个类型，那么该语句实际上是一个指针声明。这意味着c++语法是上下文敏感的。

下面是另一个例子:

foo<x> a;

同样，你可能认为这是foo类型变量“a”的声明，但它也可以被解释为:

(foo < x) > a;

这将使它成为比较表达式。

c++有一个叫做参数依赖查找(ADL)的特性。ADL建立规则来控制编译器如何查找名称。考虑下面的例子:

namespace A{
  struct Aa{}; 
  void foo(Aa arg);
}
namespace B{
  struct Bb{};
  void foo(A::Aa arg, Bb arg2);
}
namespace C{ 
  struct Cc{}; 
  void foo(A::Aa arg, B::Bb arg2, C::Cc arg3);
}

foo(A::Aa{}, B::Bb{}, C::Cc{});

ADL规则规定，考虑函数调用的所有参数，我们将寻找名称“foo”。在这种情况下，将考虑所有名为“foo”的函数进行重载解析。这个过程可能需要时间，特别是如果有很多函数重载。在模板化上下文中，ADL规则变得更加复杂。

# include

这个命令可能会极大地影响编译时间。根据所包含文件的类型，预处理器可能只复制几行代码，也可能复制数千行。

此外，编译器不能优化此命令。如果头文件依赖于宏，则可以复制可以在包含前修改的不同代码段。

对于这些问题，有一些解决方案。您可以使用预编译头文件，这是编译器在头文件中解析内容的内部表示。然而，这离不开用户的努力，因为预编译的头文件假定头文件不依赖于宏。

模块特性为这个问题提供了语言级的解决方案。它可以从c++ 20版本开始使用。

模板

The compilation speed for templates is challenging. Each translation unit that uses templates needs to have them included, and the definitions of these templates need to be available. Some instantiations of templates end up in instantiations of other templates. In some extreme cases, template instantiation can consume lots of resources. A library that uses templates and that was not designed for compilation speed can become troublesome, as you can see in a comparison of metaprogramming libraries provided at this link: http://metaben.ch/. Their differences in compilation speed are significant.

如果你想了解为什么一些元编程库在编译时间上比其他的更好，看看这个关于Chiel规则的视频。

结论

c++是一种编译缓慢的语言，因为编译性能在该语言最初开发时并不是最高优先级。结果，c++的特性在运行时可能有效，但在编译时不一定有效。

附注:我在Incredibuild工作，这是一家软件开发加速公司，专门加速c++编译，欢迎您免费试用。