c#和c++在性能方面有一些主要的区别:

c#是基于GC /堆的。分配和GC本身是内存访问的非局部性开销 多年来，c++优化器已经变得非常好。JIT编译器无法达到相同的级别，因为它们只有有限的编译时间，并且看不到全局作用域

除此之外，程序员的能力也很重要。我见过一些糟糕的c++代码，其中的类通过值作为参数传递。在c++中，如果你不知道自己在做什么，实际上会让性能变差。

没有严格的理由说明为什么基于字节码的语言(如c#或Java)不能像c++代码一样快。然而，c++代码在很长一段时间内都要快得多，今天在许多情况下仍然如此。这主要是因为更高级的JIT优化实现起来比较复杂，而真正酷的JIT优化现在才出现。

所以在很多情况下，c++更快。但这只是答案的一部分。c++实际上更快的情况是高度优化的程序，其中专业程序员彻底优化了代码。这不仅非常耗时(因此非常昂贵)，而且由于过度优化通常会导致错误。

On the other hand, code in interpreted languages gets faster in later versions of the runtime (.NET CLR or Java VM), without you doing anything. And there are a lot of useful optimizations JIT compilers can do that are simply impossible in languages with pointers. Also, some argue that garbage collection should generally be as fast or faster as manual memory management, and in many cases it is. You can generally implement and achieve all of this in C++ or C, but it's going to be much more complicated and error prone.

As Donald Knuth said, "premature optimization is the root of all evil". If you really know for sure that your application will mostly consist of very performance critical arithmetic, and that it will be the bottleneck, and it's certainly going to be faster in C++, and you're sure that C++ won't conflict with your other requirements, go for C++. In any other case, concentrate on first implementing your application correctly in whatever language suits you best, then find performance bottlenecks if it runs too slow, and then think about how to optimize the code. In the worst case, you might need to call out to C code through a foreign function interface, so you'll still have the ability to write critical parts in lower level language.

请记住，优化一个正确的程序相对容易，但更正一个优化的程序要难得多。

给出实际的速度优势百分比是不可能的，这在很大程度上取决于你的代码。在许多情况下，编程语言实现甚至不是瓶颈。请带着极大的怀疑态度使用http://benchmarksgame.alioth.debian.org/上的基准测试，因为这些测试的主要是算术代码，很可能与您的代码完全不同。

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

这是一个非常模糊的问题，没有真正明确的答案。

例如;我宁愿玩用c++而不是c#创建的3d游戏，因为性能肯定要好得多。(我知道XNA等，但它与真正的东西相去甚远)。

另一方面，如前所述;您应该使用一种能够让您快速完成所需工作的语言进行开发，并在必要时进行优化。

据我所知…

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

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

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

当有人声称“在某些领域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!

首先，我不同意这个问题的部分公认答案(并且得到了好评)，我说:

为什么jit代码比适当优化的c++(或其他没有运行时开销的语言)运行得慢，实际上有很多原因。 程序包括:

根据定义，在运行时用于jit代码的计算周期在程序执行中不可用。 JITter中的任何热路径都将与你的代码竞争指令和CPU中的数据缓存。我们知道缓存在性能方面占主导地位，而像c++这样的原生语言在设计上并没有这种类型的争用。 运行时优化器的时间预算必然比编译时优化器的时间预算更有限(正如另一个评论者指出的那样)。

底线:最终，您几乎肯定能够在c++中创建比在c#中更快的实现。

现在，说了这么多，速度到底有多快是无法量化的，因为有太多的变量:任务、问题领域、硬件、实现质量和许多其他因素。您将在您的场景上运行测试，以确定性能上的差异，然后决定是否值得额外的努力和复杂性。

这是一个很长很复杂的话题，但为了完整起见，我觉得值得一提的是，c#的运行时优化器非常出色，能够在运行时执行某些c++编译时(静态)优化器无法实现的动态优化。即便如此，优势仍然主要体现在本机应用程序方面，但动态优化器是上面给出的“几乎肯定”限定符的原因。

--

在相对性能方面，我也被我在其他一些答案中看到的数字和讨论所困扰，所以我想我应该插话，同时为我上面所做的陈述提供一些支持。

这些基准测试的很大一部分问题是，你不能像写c#一样写c++代码，并期望得到具有代表性的结果(例如。在c++中执行成千上万的内存分配将会给你可怕的数字。)

相反，我编写了稍微更习惯的c++代码，并与@Wiory提供的c#代码进行了比较。我对c++代码所做的两个主要更改是:

使用向量::储备() 将2d数组平摊到1d以获得更好的缓存位置(连续块)

c#(。净4.6.1)

private static void TestArray()
{
    const int rows = 5000;
    const int columns = 9000;
    DateTime t1 = System.DateTime.Now;
    double[][] arr = new double[rows][];
    for (int i = 0; i < rows; i++)
        arr[i] = new double[columns];
    DateTime t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);

    t1 = System.DateTime.Now;
    for (int i = 0; i < rows; i++)
        for (int j = 0; j < columns; j++)
            arr[i][j] = i;
    t2 = System.DateTime.Now;

    Console.WriteLine(t2 - t1);
}

运行时间(发布):初始:124ms，填充:165ms

C++14 （Clang v3.8/C2）

#include <iostream>
#include <vector>

auto TestSuite::ColMajorArray()
{
    constexpr size_t ROWS = 5000;
    constexpr size_t COLS = 9000;

    auto initStart = std::chrono::steady_clock::now();

    auto arr = std::vector<double>();
    arr.reserve(ROWS * COLS);

    auto initFinish = std::chrono::steady_clock::now();
    auto initTime = std::chrono::duration_cast<std::chrono::microseconds>(initFinish - initStart);

    auto fillStart = std::chrono::steady_clock::now();

    for(auto i = 0, r = 0; r < ROWS; ++r)
    {
        for (auto c = 0; c < COLS; ++c)
        {
            arr[i++] = static_cast<double>(r * c);
        }
    }

    auto fillFinish = std::chrono::steady_clock::now();
    auto fillTime = std::chrono::duration_cast<std::chrono::milliseconds>(fillFinish - fillStart);

    return std::make_pair(initTime, fillTime);
}

运行时间(发布):初始:398µs(是的，这是微秒)，填充:152ms

总运行时间:c#: 289毫秒，c++ 152毫秒(大约快90%)

观察

Changing the C# implementation to the same 1d array implementation yielded Init: 40ms, Fill: 171ms, Total: 211ms (C++ was still almost 40% faster). It is much harder to design and write "fast" code in C++ than it is to write "regular" code in either language. It's (perhaps) astonishingly easy to get poor performance in C++; we saw that with unreserved vectors performance. And there are lots of pitfalls like this. C#'s performance is rather amazing when you consider all that is going on at runtime. And that performance is comparatively easy to access. More anecdotal data comparing the performance of C++ and C#: https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=gpp&lang2=csharpcore

归根结底，c++为您提供了对性能的更多控制。你想用指针吗?一个参考吗?栈内存?堆吗?动态多态还是用静态多态(通过模板/CRTP)消除虚表的运行时开销?在c++中你必须…呃，自己做出所有这些选择(甚至更多)，理想情况下，这样你的解决方案才能最好地解决你正在处理的问题。

问问自己是否真的想要或需要该控件，因为即使对于上面的简单示例，您也可以看到尽管性能有了显著的改进，但它需要更深入的投资才能访问。