C#代码比Visual Basic.NET代码快吗？

C#代码比Visual Basic.NET代码快，还是这是一个神话？

这是一个神话。它们编译到同一个CLR。但是，同一例程的编译器在CLR中的结果可能略有不同。因此，对于某些例程，有些可能会稍微好一些，例如C#中的（0.0000001%）速度快一些，对于VB.NET则相反，但它们都运行在相同的公共运行时，因此它们在计算时的性能相同。

VB.NET中的相同代码可能比C#慢的唯一原因是VB

默认情况下，选中Visual Basic中的算术运算和溢出；在c#中，它们不是

如果禁用该选项，则生成的IL可能相同。要测试这一点，请将代码通过Reflector运行，如果从c#切换到vb.Net视图，您将看到它看起来非常相似

c#编译器与vb.net编译器之间的优化（或只是行为上的差异）可能会导致一个编译器稍微偏向另一个编译器。这是：

不太可能很重要

• 如果是的话，这将是一个很容易解决的问题

不太可能发生。

• c#和vb.net的抽象语法树在结构上非常接近。您可以将大量vb.Net自动翻译成c#，反之亦然。更重要的是，这样的结果很有可能看起来很地道

c#中有一些构造，而vb.net中没有，例如不安全的指针。在使用它们的地方，它们可能会提供一些好处，但前提是它们被实际使用，并且使用得当。如果您正在进行这种优化，您应该适当地进行基准测试。
坦率地说，如果它真的产生了很大的差异，那么问题不应该是“我应该使用哪一个c#/vb.net”，而是应该问问自己为什么不将一些代码移到c++/CLI上

我认为不同的编译器可能会带来严重的、普遍的差异，唯一的办法是：

在不同的地方实现尾部调用

• 这会使事情变得更快或更慢，并且肯定会影响深度递归函数。所有平台上的4.0 JIT编译器

更有效地实现了迭代器块或匿名lambda。

• 我相信这两个编译器在高水平上的效率与它们在这方面的表现是一样的。这两种语言都需要明确支持f#的序列生成器可用的“yield-foreach”样式

在不必要时装箱，可能是因为不使用

• 我从未见过这种情况发生，但我希望有一个这样的例子

---

c#和vb.net编译器目前都将诸如变量注册、调用约定、内联和展开等优化复杂性完全留给CLR中的通用JIT编译器。这可能会对其他任何东西产生更大的影响（特别是当32位和64位JIT现在的行为完全不同时）。

该框架是用C语言编写的，但这仍然不能说明C或VB之间的性能差异，因为所有内容都被编译为IL语言，然后实际执行（包括JITted等）

每个特定的语言编译器都有责任根据源代码生成什么类型的IL。如果其他编译器生成比其他编译器更适合的IL，那么它可能会有性能差异。我不知道是否存在这样的领域，它们会导致完全不同的IL，但我怀疑这些差异是否会它仍然是巨大的

---

另一个方面完全是C#运行不安全代码的能力，如使用原始指针等，可以在特殊情况下提供性能。

编译器优化可能略有不同，但我想说没有明显的差异。C#和VB.NET都编译为。在某些情况下，您可能能够获得显著的差异使用C语言可以提高性能，但在大多数情况下，我不建议这样做。如果您需要性能关键的东西，也不应该使用C语言

---

神话可能是因为Visual Basic 6的性能与C++的平均应用相比有很大的差异。

< P>我在微软会议上，MS的员工们说C语言比VB.NET快了8%。所以如果这是一个神话，那么如果我能找到幻灯片的话，它是由那些在MS工作的人开始的。我想，即使在某个时间点上这是真的，一个比另一个更快的唯一原因是按照ShuggyCoUk所说的默认情况下的配置方式。

像往常一样，答案是它取决于…本身，不，VB.Net并不比它慢一个C#，至少你不会注意到什么。是的，在编译器优化方面会有细微的差别，但生成的IL基本上是相同的

然而，VB.Net为使用VB6的程序员提供了一个兼容性库。我记得那些字符串方法，如左、右、中、老VB程序员所期望的。那些字符串操作函数比较慢。我不确定您是否会注意到影响，但取决于它们的使用强度，我敢打赌答案是肯定的。为什么这些方法比“本机”.net字符串方法慢？因为它们的类型安全性较差。基本上，您可以对它们抛出几乎任何东西，它们会尝试执行您希望它们执行的操作，就像在旧的VB6中一样

我正在考虑字符串操作，但如果我想得更仔细一些，我肯定我会记得在兼容层中抛出了更多的方法（我不记得程序集的名称，但记得它在VB.Net中默认被引用），如果使用这些方法而不是使用它们的.Net“na”，将对性能产生影响