C#代码比Visual Basic.NET代码更快吗?

C#代码比Visual Basic.NET代码更快,还是神话?

这是一个神话。 他们编译成同一个CLR。 但是,相同例程的编译器在CLR中可能略有不同。 因此对于某些例程,对于VB.NET,某些例程可能稍微好一点(0.0000001%),反之亦然,但它们都运行在相同的公共运行时,因此它们在性能相同时都是相同的。

vb.Net中相同代码可能比c#慢的唯一原因是VB 默认checked算术运算而c#不运行 。

默认情况下,检查Visual Basic中的算术运算和溢出; 在c#中,它们不是。

如果禁用它,那么生成的IL可能是相同的。 要对此进行测试,请使用代码并通过Reflector运行它,如果从c#切换到vb.Net视图,您将看到它看起来非常相似。

c#编译器中的优化(或只是行为上的差异)可能与vb.net编译器相比可能导致一个稍微偏向另一个。 这是:

  1. 不太重要
    • 如果它是固定的低水果
  2. 不太可能发生。
    • c#和vb.net的抽象语法树结构非常接近。 你可以自动将大量的vb.Net音译成c#,反之亦然。 更重要的是,结果将是寻找惯用语的好机会。

c#中的一些构造不在vb.net中,例如不安全的指针。 使用时,它们可能会提供一些好处,但只有在实际使用时才能正常使用。 如果您需要进行这种优化,那么您应该适当地进行基准测试。
坦率地说,如果它产生了很大的不同,那么问题不应该是“我应该使用哪个c#/ vb.net”而应该问你自己为什么不将一些代码转移到C ++ / CLI。

我能想到不同的编译器可以引入严重的,普遍的差异的唯一方法是,如果有人选择:

  1. 在不同的地方实现尾调用
    • 这些可以使事情更快或更慢,当然会影响深度递归函数。 所有平台上的4.0 JIT编译器现在都会遵守所有尾调用指令,即使它必须做很多工作才能实现它 。
  2. 更有效地实现迭代器块或匿名lambdas。
    • 我相信这两个编译器在高水平上的效率都与它们在这方面要达到的效率相当。 两种语言都需要明确支持f#序列生成器可用的“yield foreach”样式。
  3. 在没有必要的情况下装箱,也许不使用受约束的操作码
    • 我从来没有见过这种情况,但会喜欢它的例子。

c#和vb.net编译器目前都存在这样的优化复杂性,如注册变量,调用约定,内联和展开完全取决于CLR中的通用JIT编译器。 这可能会对其他任何事情产生更大的影响(特别是当32位和64位JIT现在可以表现得完全不同时)。

该框架是用C#编写的,但仍然没有告诉C#或VB之间的性能差异,因为所有内容都被编译为IL语言 ,然后实际执行(包括JITted等)。

责任在于每个特定的语言编译器,它们基于源代码生成什么样的IL。 如果其他编译器产生比其他编译器更适合的IL,则它可能具有性能差异。 我不知道究竟是否存在这样一个区域,它们会造成完全不同的IL,但我怀疑差异仍然很大。

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

编译器优化可能略有不同,但我认为没有明显的区别。 C#和VB.NET都编译为Common Intermediate Language 。 在某些情况下,您可以通过使用不安全的代码在C#中获得显着的性能提升,但在大多数情况下我不建议这样做。 如果你需要性能至关重要的东西,你也不应该使用C#。

这个神话可能是因为与普通的C ++应用程序相比,Visual Basic 6性能的巨大差异。

这取决于你在做什么。 我认为VB和C#之间没有真正的区别。 它们都是.Net语言,它们是用IL编译的。

更多信息? 读这个:

http://devlicio.us/blogs/robert_dunaway/archive/2006/10/19/To-use-or-not-use-Microsoft.VisualBasic.dll-_2800_all-.NET-Languages-could-benefit_3F002900_.aspx

我参加了微软会议,MS员工声称C#比VB.NET快8%。 因此,如果这是一个神话,它是由在MS工作的人开始的。 如果我能找到说明这个的幻灯片,我会发布它们,但这就是C#刚出来的时候。 我认为即使在某个时间点确实如此,一个人比另一个人更快的唯一原因就是像ShuggyCoUk所说的那样默认配置。

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

但是,VB.Net为兼容VB6的程序员提供了兼容性库。 我记得那些字符串方法,如左,右,中,老VB程序员会期望的。 那些字符串操作函数较慢。 我不确定你会注意到影响,但根据使用强度,我敢打赌答案是肯定的。 为什么这些方法比“native”.net字符串方法慢? 因为它们的类型安全性较低。 基本上,你几乎可以扔任何东西,他们会尝试做你想要的东西,就像在旧的VB6中一样。

我正在考虑字符串操作,但如果我认为更难,我相信我会记住更多的方法被抛入该兼容层(我不记得程序集的名称,但记住它在VB.Net中默认引用)如果使用它而不是它们的.net“原生”等价物会产生性能影响。

所以,如果你像VB6一样继续编程,那么你可能会注意到一个影响。 如果没有,那没关系。

生成的代码中存在一些小差异,这些差异可能会使C#在某些情况下略微加快。 例如,VB.NET有一些额外的代码来清除方法中的局部变量,而C#则没有。

但是,这些差异几乎无法衡量,而且大多数代码都不是最优的,只是通过切换语言以使代码运行得更快而刚刚开始。 您可以使用任何CPU密集型代码,而且可以轻松地将其提高两倍。 有些代码可以快10倍,其他代码可能快10000倍。 在这种情况下,使用C#而不是VB.NET可能获得的百分之几是不值得的。

另一方面,学习C#可能是加速代码的有效方法。 不是因为C#可以生成更快的代码,而是因为您将更好地理解C#和VB.NET,使您能够编写在任何一种语言中都能表现更好的代码。

编辑:
C#和VB.NET编译器显然或多或少地同步开发。 C#1和C#2之间的速度差异大约为30%,C#和VB.NET的并行版本之间的差异要小得多。

这不是一个神话。 虽然C#和VB.Net都编译为IL,但实际生成的指令可能会有所不同,因为1.编译器可能有不同的优化,以及2.默认情况下VB.Net执行的额外检查,例如算术溢出。 所以在很多情况下性能会相同但在某些情况下C#会更快。 在极少数情况下,VB.Net也可能更快。

C#和VB.Net都是由IL编译的。 C ++和F#也是由它编译的。 事实上,我提到的四种语言以相同的速度执行。 这些“更快的语言”没有:独特的区别在于自动垃圾收集语言(C#,VB.Net,F#等)和那些不自动收集的语言(如C ++)。 第二组通常较慢,因为开发人员很少知道如何以及何时收集堆内存中的垃圾,但是,如果您了解堆内存,则在C ++中程序可能会更快。 硬图形程序通常用C ++编写(例如大多数Adobe程序)。 您也可以在C#( System.GC.Collect(); )和VB.Net( System.GC.Collect )中手动收集垃圾。 我知道这个问题的答案并不是完全固有的,但我想为你提供很多方法和选择。 您为程序选择了正确的方法。