令人惊讶的是，“C/ c++必须比Java快，因为Java是解释性的”的神话仍然活跃。有几年前的文章，也有最近的文章，用概念或测量来解释为什么这种情况并不总是如此。

当前的虚拟机实现(顺便说一下，不仅仅是JVM)可以利用程序执行期间收集的信息来动态地优化代码，使用各种技术:

将频繁的方法呈现给机器代码， 内联小方法， 锁紧调整

以及各种其他调整，这些调整是基于了解代码实际在做什么，以及它运行的环境的实际特征。

c语言并没有什么特别之处，这也是它速度快的原因之一。

新语言支持垃圾收集、动态类型和其他功能，使程序员更容易编写程序。

问题在于，会有额外的处理开销，这会降低应用程序的性能。C语言没有这些，这意味着没有开销，但这意味着程序员需要能够分配内存并释放它们以防止内存泄漏，并且必须处理变量的静态类型。

也就是说，许多语言和平台，如Java(其Java虚拟机)和。net(其公共语言运行时)，多年来通过即时编译(从字节码生成本机机器代码以实现更高性能)等技术改进了性能。

我还没有看到它，所以我要说:C往往更快，因为几乎所有其他东西都是用C写的。

Java是建立在C上的，Python是建立在C上的(或者Java，或者。net等等)，Perl是等等。操作系统是用C写的，虚拟机是用C写的，编译器是用C写的，解释器是用C写的，有些东西仍然是用汇编语言写的，这往往更快。越来越多的东西是用别的东西写的，而这些东西本身就是用C写的。

您用其他语言(不是Assembly)编写的每个语句通常都在下面实现为C中的几个语句，这些语句被编译为本机机器代码。由于其他语言的存在往往是为了获得比C更高的抽象级别，因此C中所需的那些额外语句往往侧重于增加安全性、增加复杂性和提供错误处理。这些通常都是好事，但它们是有代价的，那就是速度和规模。

就我个人而言，我已经用几十种语言写过了，涵盖了大部分可用的范围，我个人也一直在寻找你暗示的魔法:

我怎样才能鱼与熊掌兼得呢?我如何在我最喜欢的语言中玩高级抽象，然后为了速度而降至C语言的细节?

经过几年的研究，我的答案是Python(在C上)。你可能想看看它。顺便说一下，您也可以从Python下拉到Assembly(从一个特殊的库中获得一些小小的帮助)。

另一方面，任何语言都可能编写出糟糕的代码。因此，C(或汇编)代码不会自动更快。同样，一些优化技巧可以使部分高级语言代码的性能水平接近原始c语言的性能水平。但是，对于大多数应用程序来说，程序的大部分时间都在等待人员或硬件，因此两者之间的差异实际上并不重要。

享受。

C语言速度很快，因为它是原生编译的低级语言。但是C不是最快的。递归斐波那契基准测试表明Rust、Crystal和Nim可以更快。

c++的平均速度更快(就像它最初一样，主要是C的超集，尽管有一些不同)。然而，对于特定的基准测试，通常有另一种更快的语言。

https://benchmarksgame-team.pages.debian.net/benchmarksgame/

fannjuch-redux是Scala中最快的

n-body和fasta在Ada中更快。

频谱范数在Fortran中是最快的。

反补、mandelbrot和pidigits在ATS中最快。

regex-dna是JavaScript中最快的。

chameneau -redux最快的是Java 7。

Haskell的螺纹环速度最快。

其余的基准测试在C或c++中是最快的。

这实际上是一个长期存在的谎言。虽然C程序确实经常更快，但情况并非总是如此，特别是当C程序员不太擅长它的时候。

人们往往会忘记的一个明显的漏洞是，当程序必须为某种IO阻塞时，比如任何GUI程序中的用户输入。在这些情况下，使用什么语言并不重要，因为您受到数据传入速度的限制，而不是处理数据的速度。在这种情况下，不管你使用的是C、Java、c#甚至Perl;你不能比数据进入的速度更快。

The other major thing is that using garbage collection and not using proper pointers allows the virtual machine to make a number of optimizations not available in other languages. For instance, the JVM is capable of moving objects around on the heap to defragment it. This makes future allocations much faster since the next index can simply be used rather than looking it up in a table. Modern JVMs also don't have to actually deallocate memory; instead, they just move the live objects around when they GC and the spent memory from the dead objects is recovered essentially for free.

This also brings up an interesting point about C and even more so in C++. There is something of a design philosophy of "If you don't need it, you don't pay for it." The problem is that if you do want it, you end up paying through the nose for it. For instance, the vtable implementation in Java tends to be a lot better than C++ implementations, so virtual function calls are a lot faster. On the other hand, you have no choice but to use virtual functions in Java and they still cost something, but in programs that use a lot of virtual functions, the reduced cost adds up.