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

從效率上看，是不是所有的.NET語言都擁有同樣的執行效率呢？這裡的答案可能使你驚訝。來看看Lamont Adams 從深層次代碼分析得到的結果。

VB.NET vs. C#, round 2: Pounding on performance
Dec 3, 2001
Lamont Adams
Authors Bio | E-Mail | Archive

If theres one property that all new technologies share as they pass through their infancy, its 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#?," Microsofts 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 Microsofts new development platform, send it my way. Ill 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: Ive 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 havent seen anything that would point to C# having a speed advantage and therefore didnt 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.

Thats 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 FilesMicrosoft.NetFrameworkSDKSamplesapplications ypefinder) and compiled them both. Next, I took the resulting executable files and ran them through the MSIL disassembler utility (Program FilesMicrosoft.NetFrameworkSDKBinildasm.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# compilers 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 latters best time was slightly slower than the formers worst time.

Whats going on here?

Im no expert on IL, and its 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 Microsofts 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 whats going on here. Send me an e-mail with your explanation.

Something strange is afoot

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