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

. net语言可以像c++代码一样快，甚至更快，但是c++代码将拥有更恒定的吞吐量，因为. net运行时必须暂停进行GC，即使它非常巧妙地处理了暂停。

因此，如果您有一些代码必须持续快速运行而不需要任何暂停，. net在某些时候会引入延迟，即使您非常小心地使用运行时GC。

I suppose there are applications written in C# running fast, as well as there are more C++ written apps running fast (well C++ just older... and take UNIX too...) - the question indeed is - what is that thing, users and developers are complaining about ... Well, IMHO, in case of C# we have very comfort UI, very nice hierarchy of libraries, and whole interface system of CLI. In case of C++ we have templates, ATL, COM, MFC and whole shebang of alreadyc written and running code like OpenGL, DirectX and so on... Developers complains of indeterminably risen GC calls in case of C# (means program runs fast, and in one second - bang! it's stuck). To write code in C# very simple and fast (not to forget that also increase chance of errors. In case of C++, developers complains of memory leaks, - means crushes, calls between DLLs, as well as of "DLL hell" - problem with support and replacement libraries by newer ones... I think more skill you'll have in the programming language, the more quality (and speed) will characterize your software.

我发现2020年4月读过:https://www.quora.com/Why-is-C-so-slow-compared-to-Python，作者是一位拥有15年以上软件开发经验的现实世界的程序员。

它指出，c#通常较慢，因为它被编译为公共中间语言(CIL)，而不是像c++那样的机器代码。然后，CIL通过公共语言运行库(CLR)输出机器代码。但是，如果您继续执行c#，它将获取机器代码的输出并缓存它，以便为下次执行保存机器代码。总而言之，如果多次执行，c#会更快，因为它是多次执行后的机器代码。

也有评论说，一个优秀的c++程序员可以做一些耗时的优化，但最终会被优化。

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)为您提供了对数据结构的细粒度控制。如果你想玩，你有这个选择。大型托管Java或。net应用程序(OWB, Visual Studio 2005)，它们使用Java/。NET库自带包袱。我曾见过OWB设计会话使用超过400 MB的RAM，立方体或ETL设计的bid也达到100 MB。

在可预测的工作负载上(例如重复一个过程多次的大多数基准测试)，JIT可以为您提供优化得足够好的代码，没有实际差别。

在大型应用程序上，差异与其说是JIT，不如说是代码本身使用的数据结构。当应用程序的内存很重时，您将获得较低的缓存使用效率。在现代cpu上，缓存丢失是非常昂贵的。C或c++的真正优势在于，您可以优化数据结构的使用，从而更好地使用CPU缓存。