In theory, for long running server-type application, a JIT-compiled language can become much faster than a natively compiled counterpart. Since the JIT compiled language is generally first compiled to a fairly low-level intermediate language, you can do a lot of the high-level optimizations right at compile time anyway. The big advantage comes in that the JIT can continue to recompile sections of code on the fly as it gets more and more data on how the application is being used. It can arrange the most common code-paths to allow branch prediction to succeed as often as possible. It can re-arrange separate code blocks that are often called together to keep them both in the cache. It can spend more effort optimizing inner loops.

我怀疑。net或任何jre都能做到这一点，但早在我上大学的时候就有人在研究这一点，所以认为这类东西很快就会在现实世界中找到自己的方式也不是不合理的。

对于图形来说，标准的c#图形类比通过C/ c++访问的GDI慢得多。 我知道这与语言本身无关，更多的是与整个。net平台有关，但是图形是作为GDI替代品提供给开发人员的，它的性能非常糟糕，我甚至不敢用它来处理图形。

我们有一个简单的基准来查看图形库的速度，那就是在窗口中随机绘制线条。c++ /GDI在处理10000行代码时仍然很灵活，而c# /Graphics在处理1000行代码时却很难做到。

通常，这取决于应用程序。在某些情况下，c#可能慢得可以忽略不计，而在其他情况下，c++要快5到10倍，特别是在操作可以轻松SIMD的情况下。

C/ c++在有大型数组或数组(任何大小)上的大量循环/迭代的程序中可以表现得更好。这就是为什么在C/ c++中图形化通常要快得多，因为几乎所有的图形化操作都基于繁重的数组操作。net在数组索引操作中是出了名的慢，这是由于所有的安全检查，这对于多维数组尤其如此(是的，矩形c#数组甚至比锯齿形c#数组还要慢)。

The bonuses of C/C++ are most pronounced if you stick directly with pointers and avoid Boost, std::vector and other high-level containers, as well as inline every small function possible. Use old-school arrays whenever possible. Yes, you will need more lines of code to accomplish the same thing you did in Java or C# as you avoid high-level containers. If you need a dynamically sized array, you will just need to remember to pair your new T[] with a corresponding delete[] statement (or use std::unique_ptr)—the price for the extra speed is that you must code more carefully. But in exchange, you get to rid yourself of the overhead of managed memory / garbage collector, which can easily be 20% or more of the execution time of heavily object-oriented programs in both Java and .NET, as well as those massive managed memory array indexing costs. C++ apps can also benefit from some nifty compiler switches in certain specific cases.

I am an expert programmer in C, C++, Java, and C#. I recently had the rare occasion to implement the exact same algorithmic program in the latter 3 languages. The program had a lot of math and multi-dimensional array operations. I heavily optimized this in all 3 languages. The results were typical of what I normally see in less rigorous comparisons: Java was about 1.3x faster than C# (most JVMs are more optimized than the CLR), and the C++ raw pointer version came in about 2.1x faster than C#. Note that the C# program only used safe code—it is my opinion that you might as well code it in C++ before using the unsafe keyword.

Lest anyone think I have something against C#, I will close by saying that C# is probably my favorite language. It is the most logical, intuitive and rapid development language I've encountered so far. I do all my prototyping in C#. The C# language has many small, subtle advantages over Java (yes, I know Microsoft had the chance to fix many of Java's shortcomings by entering the game late and arguably copying Java). Toast to Java's Calendar class anyone? If Microsoft ever spends real effort to optimize the CLR and the .NET JITter, C# could seriously take over. I'm honestly surprised they haven't already—they did so many things right in the C# language, why not follow it up with heavy-hitting compiler optimizations? Maybe if we all beg.

需要大量内存访问的应用程序。图像处理通常更适合在非托管环境(c++)而不是托管环境(c#)中编写。使用指针算法优化的内循环在c++中更容易控制。在c#中，你可能需要使用不安全的代码来获得相同的性能。

我想这么说:编写更快代码的程序员，是那些更了解当前机器运行速度的人，顺便说一句，他们也是那些使用适当工具的人，这些工具允许精确的低级和确定性优化技术。由于这些原因，这些人使用C/ c++而不是c#。我甚至认为这是事实。