I have heard that C++ .NET is fastest , C# is next, followed by VB .NET and Languages like Iron-Python and Boo come last in terms of performance. If all .NET languages compile to intermediate byte-code which is the same, why the difference in performance?

It is understandable for Boo and Python as all the types have to be evaluated at runtime. But why the difference between languages like C++ and C#?

I'm curious what your sources are for what you've heard about performance. I also wouldn't assume that because all .NET languages compile to IL that they all compile to the SAME IL. You can do the same thing in dozens of ways in any language - IL would be no exception.
–
The Evil GreeboJun 28 '11 at 15:43

6

There is no performance difference between C# and VB.NET
–
brokeJun 28 '11 at 15:45

1

Language performance is extremely subjective. Poorly written CLI would execute slower than well written C#.
–
Brandon MoretzJun 28 '11 at 15:47

My sources are usually blogs and articles around various websites, wait a minute while I try to find them.
–
ApprenticeHackerJun 28 '11 at 15:47

1

Comparing language speed can be very tricky. Some languages have advantages in some areas while others are faster doing other things. Also the programmer has a lot to do with it.
–
m4tt1musJun 28 '11 at 15:47

5 Answers
5

Python performs worse because it is interpreted, not compiled. Instead of being converted to CIL (common intermediate language) before being run, it is converted at run time, which obviously will incur performance overhead.

Also, since IronPython is dynamically-typed, fewer optimizations can be made when compared to statically typed languages (which C++, C#, and, despite the Pythonesque syntax, Boo as well, are).

You also have to consider the amount of effort put into making optimizations to each implementation. C# and C++.NET have huge teams at Microsoft working on making their compilers produce the fastest bytecode possible. IronPython and Boo are volunteer projects that don't have nearly as much manpower or resources, so they won't gain optimizations as quickly as something MS-funded.

Essentially, language features can have performance/memory costs at both compile-time and runtime. That is why .NET languages vary in performance; because they vary in features.

I see. So the high level features of C# like delegates and events require more memory and compile to more byte-code than C++ equivelants?
–
ApprenticeHackerJun 28 '11 at 15:58

@burningprodigy it depends. I imagine that some of C#'s language features are more resource intensive than C++ features that accomplish the same thing, but I can't speak to whether specific features are more demanding (like delegates or events) because I'm not familiar with the compiler or C#.
–
Rafe KettlerJun 28 '11 at 16:00

I fixed the boo doubts you had. Just because the syntax is similar, it doesn't mean it's the same. Boo is statically typed with type inference all over, but it also supports dynamic typing.
–
R. Martinho FernandesSep 21 '11 at 6:08

All of the answers so far have confused C++ and "C++ .Net" (which is actually now called C++/CLI) - these are two completely separate languages.

C++ is compiled to native machine code. C++/CLI is compiled to CIL (.Net) bytecode. Because of this, C++ programs will tend to be a bit faster than C++/CLI code. C++ is about 30 years old, and is widely used in the programming world. C++/CLI, on the other hand, is about 10 years old, and is not widely utilized. Its main purpose is to make translating C++ programs onto .Net much easier - going from C++ to C++/CLI is a lot less work than going from C++ to C#.

There is another confusion in one of your comments above: between VB6 and VB.Net. VB6 was Microsoft's old VB language, now deprecated. It was compiled to native machine code, though there was a widespread belief (mostly true) that it was slower than C++. VB.Net is Microsoft's new VB language, compiled to CIL.

Now: performance. C++ is usually going to be the fastest, simply because it's compiled to native machine code, and because people have been working on optimizing its compilers for 30 years. This is what you'll usually see video games and other high-performance applications written in, but, compared to the other languages, it's kind of a pain to work with.

Between .Net languages, the two big ones - C# and VB.Net - are mostly the same performance-wise. Though I have no benchmarks to prove this, I would guess that C++/CLI is actually slightly slower, simply because Microsoft hasn't put as much emphasis on that language, so there probably aren't as many programmers working on optimizing its compiler.

IronPython, since it does not have a full-time team working to optimize its compiler, is probably going to be the slowest. It also runs above the DLR, which is just another layer of indirection. Also, another answer states that it's interpreted, which would be a performance-killer.

C++/CIL can be faster. The good point is that you can switch there between NATIVE and CIL code on a PER METHOD BASIS (even in the same class). It is mostly usefull to bidge between native API#s from third parties and .NET programs - some native stuff is awkward and painfull to code from C# and a lot easier from C++, and some API's are coming as C++ object libraries or with a C++ FILE (code) SDK attached with tons of helper methods.
–
TomTomJun 28 '11 at 19:42

2

Slight correction, VB6 was not always compiled to native, there was still the option for P-Code. P-Code was usually slower than native, but I think there were a few certain cirumstances when P-Code might be faster.
–
Hans OlssonJun 29 '11 at 8:50

C++/CLI isn't compiled to pure MSIL (depending on your compilation flags) - it is, by default, done in IJW (It Just Works) mode - where bits that don't use the CLI are compiled to native code (and the compiler sets up the shims to talk between them). IJW can actually be slower depending on how often the CLR needs to change contexts to native (i.e. it's best to do a lot in each context and change infrequently), but you can do hotspots in pure native code. (Similar to what TomTom said, just with the performance considerations).
–
Jonathan DickinsonJan 3 '12 at 13:19

Sometimes operations that appear equivalent may actually involve a little extra work (done automatically by the compiler) to conform to language requirements. For example in VB, there are quirks like whenever you catch an exception it updates the Err object; whenever you do almost anything with an Object variable it calls a function that makes a copy in case it is a value type.

Nice answer, I didn't know VB did all this heavy-lifting. Another thing to note is that VB uses a different call type (call instead of callvirt I think) which is slower to JIT - to maintain behavioural compatibility with VB6.
–
Jonathan DickinsonJan 3 '12 at 13:30

Following C++ instincts in C++/cli will lead to faster code than using C# instincts in C#, e.g. when looping through data. Sure, You CAN use unsafe C# code to accomplish the same thing and you CAN use arrays in C++/cli, but if instead you follow fairly standard language paradigms there can be a huge performance difference in the right circumstances, e.g. 10 to 1 in a tight loop with plenty of data access.

C++ paradigm in C++/cli

char * position = start;
char * end = position + data_count;
while ( position < start ) {
{ do stuff with the data )
position ++;
}

C# paradigm

for ( int i = 0 ; i < count; i ++ ) {
{ do stuff with data[i] )
}

Use the dissassembly window and you will see how very differently these compile.

Besides these programming paradigm issues there may be actual compiler issues, but I don't know anything about those.