当前位置: 王朝网络 >> c# >> VB.NET vs. C#: 效率直击

VB.NET vs. C#: 效率直击

王朝c#·作者佚名 2006-01-08

从效率上看，是不是所有的.NET语言都拥有同样的执行效率呢？这里的答案可能使你惊讶。来看看Lamont Adams 从深层次代码分析得到的结果。

VB.NET vs. C#, round 2: Pounding on performance

Dec 3, 2001

Lamont Adams

If there's one property that all new technologies share as they pass through their infancy, it's an excess of questions about them. Judging by the number of questions we received in response to our recent article "The three-million-programmer question: VB.NET or C#?," Microsoft's new .NET development framework is no different.

Hence, we decided to launch a new Developer Republic column, .NET Answers. Aside from using this space to challenge English punctuation rules on a regular basis, I hope to answer your questions about .NET development. So if you have a question about Microsoft's new development platform, send it my way. I'll take my best shot at it.

We received our inaugural question from member Vladimir Srecovic, from Yugoslavia, in response to the article referenced above. Vladimir has a question about performance.

C# performance benchmarking

Q: I've seen reports that C#-produced IL (Intermediate Language) code runs faster than VB.NET-produced code. Is this true?

Vladimir Srecovic

A: I was all set to respond to this question with a negative answer. I haven't seen anything that would point to C# having a speed advantage and therefore didn't think it likely that any significant performance difference would exist. After all, IL code is compiled to native code by the same Just In Time (JIT) compiler, regardless of which IL compiler generated it. So in theory at least, as long as your IL compiler was built to standard, equivalent VB.NET, C#, or even COBOL.NET code would compile into essentially the same IL code.

That's the conventional wisdom, anyway. Being the thorough type, though, I decided to perform a little experiment to see if this reasoning bore out. I took the VB.NET and C# versions of the TypeFinder sample application (look for it in \Program Files\Microsoft.Net\FrameworkSDK\Samples\applications\typefinder) and compiled them both. Next, I took the resulting executable files and ran them through the MSIL disassembler utility (\Program Files\Microsoft.Net\FrameworkSDK\Bin\ildasm.exe) to view the IL that both compilers produced. I then compared the two pieces of IL that were generated for the rather simple method IndentedWriter.WriteLine. You can see the VB.NET source for this method in Figure A. The C# source is shown in Figure B.

Figure A

The VB.NET version is slightly longer than the C# version.

Figure B

The C# version takes seven lines of code.

I was surprised by what I discovered when I compared the resulting IL code: The VB.NET version was nine lines (and 9 KB) longer than the C# version. You can see the IL that the VB.NET compiler generated in Listing A; the C# compiler's results appear in Listing B.

After comparing the code, I did a little quick and dirty benchmarking and found that over 12 trials, the C# version of FindType.exe, which uses reflection to list the methods belonging to a particular object, narrowly outperformed the VB.NET version. The latter's best time was slightly slower than the former's worst time.

What's going on here?

I'm no expert on IL, and it's currently poorly documented. But from looking at the IL code, it seems obvious that even though the two pieces of source are functionally identical and perform the same tasks in the same order, the resulting IL code is quite different:

Five of the extra opcodes generated by the VB.NET compiler are nop, which, according to Microsoft's current documentation, stands for "No Operation" or "pass."

The VB.NET IL declares an extra local variable of type int32 in the .locals section. This local variable is apparently used to cache a copy of the IndentedWriter.myIndent field for use in the for loop (line IL_002b). The C# IL, on the other hand, refers to the class field directly in line IL_0021).

The VB.NET IL uses six opcodes (IL_0000 to IL_000e) to create its StringBuilder object, while the C#-generated IL uses only five (IL_0000 to IL_000d). One of the VB.NET opcodes used here is a nop.

Both for loops are implemented in 13 opcodes (lines IL_001a through IL_002c for VB.NET and lines IL_0010 to IL_0026 for C#). Interestingly though, one of the opcodes in the VB.NET for loop is a nop.

Anyone care to explain this?

I would like to hear from any IL gurus that can more adequately explain what's going on here. Send me an e-mail with your explanation.

Something strange is afoot

Although there's no smoking gun here, it does appear that the VB.NET compiler generated slightly less efficient code than its C# counterpart. That would seem to support the conclusion that, at least in this example, C# does in fact outperform equivalent VB.NET code. All this could change since we are still dealing with a beta. So stay tuned. There may be another chapter to this story yet.

Listing A: IL generated by VB.NET

.method public hidebysig instance void WriteLine(string message) cil managed

{

// Code size 75 (0x4b)

.maxstack 3

.locals init ([0] int32 i,

[1] class [mscorlib]System.Text.StringBuilder sb,

[2] int32 _Vb_t_i4_0)

IL_0000: nop

IL_0001: ldarg.0

IL_0002: ldfld bool NetSDKSamples.IndentedWriter::myPrintFlag

IL_0007: brfalse.s IL_0048