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

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

. 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.

快了5个橘子。或者更确切地说:不可能有一个(正确的)笼统的答案。c++是一种静态编译语言(但也有配置文件引导的优化)，c#在JIT编译器的帮助下运行。它们之间的差异如此之大，以至于像“快了多少”这样的问题都无法回答，甚至无法给出数量级。

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

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

据我所知…

你的困难似乎在于决定你所听到的是否可信，当你试图评估这个网站上的回复时，这个困难将会重复。

你将如何判断人们在这里所说的比你最初听到的更可信还是更不可信?

一种方法是要求提供证据。

当有人声称“在某些领域c#被证明比c++快”时，问他们为什么这么说，让他们给你看测量结果，让他们给你看程序。有时他们只是犯了一个错误。有时你会发现他们只是在表达一种观点，而不是分享一些他们可以证明是正确的事情。

通常情况下，信息和观点会混淆在人们的说法中，你必须试着分清哪个是哪个。例如，从这个论坛的回复中:

"Take the benchmarks at http://shootout.alioth.debian.org/ with a great deal of scepticism, as these largely test arithmetic code, which is most likely not similar to your code at all." Ask yourself if you really understand what "these largely test arithmetic code" means, and then ask yourself if the author has actually shown you that his claim is true. "That's a rather useless test, since it really depends on how well the individual programs have been optimized; I've managed to speed up some of them by 4-6 times or more, making it clear that the comparison between unoptimized programs is rather silly." Ask yourself whether the author has actually shown you that he's managed to "speed up some of them by 4-6 times or more" - it's an easy claim to make!