tags:

views:

1161

answers:

11

Is C# code faster than Visual Basic.NET code, or that is a myth?

+38  A: 

That is a myth. They compile down to the same CLR. However the compiler for the same routine may come out slightly differently in the CLR. So for certain routines some may be slightly better like (0.0000001%) faster in C# and vice versa for VB.NET, but they are both running off the same common runtime so they both are the same in performance where it counts.

Nick Berardi
Compiling down to the same IL is not a guarantee that the same optimizations are applied. Do you have a reference that performance will be similar?
0xA3
I agree, but with one small caveat: if you have Option Strict off, you're essentially doing extra conversions everywhere, which often makes code significantly slower. You can't make this same mistake with C#, which can lead to performance improvements if you rewrite VB.NET code in C#.
Daniel Pryden
Of course, any developer worth their salt would have Option Strict On.
Bob King
@divo : yes it is if you have the same il and same attibutes on a dll then it is identical in behaviour no matter which compiler made it... that's sort of the whole point of intermediate languages
ShuggyCoUk
My point was that you won't get the exact same IL instructions because the IL is generated by different compilers (cf the answer of Dreas Grech)!
0xA3
ah I see - you meant compiling down to the same underlying il rather than specific instructions. I follow you now.I believe the optimizations are kept in reasonable sync (and they are fairly minor as well)
ShuggyCoUk
@Shuggy: the point is that the C# and VB.Net compilers often do produce different IL and the C# compiler generally produces faster code, given the default respective compiler options.
Matt Howells
@divo that is true, because the C# compiler uses a different routine than the VB.NET compiler you are going to get slightly different IL. But the real question is, is there going to be a noticeable performance difference or one that is measurable to something within 1/10000 of a milisecond? And I contend that you won't find any measurable performance difference between C# and VB.NET as long as the same optimizations are turned on.
Nick Berardi
@Nick: I tried finding some reference but all I could found was rather outdated figures on performance comparison. And even worse the results were contradicting. Do you have any up-to-date and reliable figures that lead to your statement?
0xA3
No, I found the same thing on Google. I think I will do a blog post on this at http://coderjournal.com, since this seems to have struck a nerve and needs a more updated reference for the .NET 3.5 framework.
Nick Berardi
I'd love to see a specific code example where the current compilers produce significant il differences. I'd further love to see whether the JIT doesn't then produce the same code...
ShuggyCoUk
modulo the default checked behaviour obviously
ShuggyCoUk
I have no evidence of VB.Net generating less optimum IL than C#, at least nothing that can be felt. However, don't forget the assembly it references by default that comes with Left, Mid, Right, etc, etc. To emulate VB6, it does loads of boxing and other slower things than "native" .net methods. These only represent an impact if used.
Rui Craveiro
but you can use those in c# as well - just include the VB assembly...
ShuggyCoUk
@Rui - I thought that those were all wrappers around .SubString, .Contains, etc. anymore anyway.
Bob King
@Bob King: You're right, if you take a look with Reflector you will see that Mid calls Substring internally, for instance.
Meta-Knight
@Bob King: They are wrappers, but not just wrappers. Most of them do some additional checking for example to handle null values or out of bounds indexes differently.
Guffa
+20  A: 

The only reason that the same code in vb.Net might be slower than c# is that VB defaults to have checked arithmetic on and c# doesn't.

By default, arithmetic operations and overflows in Visual Basic are checked; in c#, they are not.

If you disable that then the resulting IL is likely to be identical. To test this take your code and run it through Reflector and you will see that it looks very similar if you switch from c# to vb.Net views.

It is possible that an optimization (or just difference in behaviour) in the c# compiler verses the vb.net compiler might lead to one slightly favouring the other. This is:

  1. Unlikely to be significant
    • if it was it would be low hanging fruit to fix
  2. Unlikely to happen.
    • c# and vb.net's abstract syntax trees are very close in structure. You could automatically transliterate a great deal of vb.Net into c# and vice versa. What is more the result would stand a good chance of looking idiomatic.

There are a few constructs in c# not in vb.net such as unsafe pointers. Where used they might provide some benefits but only if they were actually used, and used properly. If you are down to that sort of optimization you should be benchmarking appropriately.
Frankly if it makes a really big difference then the question should not be "Which of c#/vb.net should I use" you should instead be asking yourself why you don't move some code over to C++/CLI.

The only way I could think of that the different compilers could introduce serious, pervasive differences is if one chose to:

  1. Implement tail calls in different places
  2. Implemented iterator blocks or anonymous lambdas significantly more efficiently.
    • I believe both compilers are about as efficient at a high level as they are going to get though in this regard. Both languages would require explicit support for the 'yield foreach' style available to f#'s sequence generators.
  3. Boxed when it was not necessary, perhaps by not using the constrained opcode
    • I have never seen this happen but would love an example where it does.

Both the c# and vb.net compilers currently leave such optimization complexities as en-registering of variables, calling conventions, inlining and unrolling entirely up to the common JIT compiler in the CLR. This is likely to have far more of an impact on anything else (especially when the 32 bit and 64bit JIT's can now behave quite differently).

ShuggyCoUk
+4  A: 

The framework is written in C# but that still does not tell about performance differences between C# or VB as everything is compiled to IL language which then actually executed (including JITted and so on).

The responsibility is on each specific language compiler that what kind of IL they produce based on source code. If other compiler produces better suited IL than other, then it could have performance difference. I don't know exactly that is there this kind of areas where they would cause drastically different IL, but I doubt the differences would still be huge.

Other aspect is completely then the C#'s ability to run unsafe code like using raw pointers etc that can give performance on special scenarios.

Andreas Grech
+4  A: 

There might be a slight difference in the compiler optimization, but I'd say there is no noticeable difference. Both C# and VB.NET compile to Common Intermediate Language. In some cases, you may be able to get a significant performance gain in C# by using unsafe code, but under most circumstances I wouldn't recommend doing so. If you need something that performance critical, you shouldn't use C# either.

The myth probably started because of the huge difference in Visual Basic 6 performance compared to the average C++ application.

Thorarin
I agree, VB.net carries the bad reputation of VB6 despite of the fact they're different.
yelinna
+1  A: 

I was at a Microsoft conference and the MS employees stated that C# is up to 8% faster than VB.NET. So if this is a myth, it was started by the peple that work at MS. If I can find the slides that state this I would post them, but this was when C# just came out. I think that even if it was true at one point in time, that the only reason for one to be faster than the other is how things are configured by default like ShuggyCoUk said.

SteveM
"Up to" 8%. In which circumstances? And what's the performance difference in the other circumstances? Are there any circumstances where VB.NET is faster? You can't tell from a quick "up to 8%" statement.
John Saunders
You are absolutely right, but everyone was so excited about C# at the start of it that they didn't ask the questions.
SteveM
+1  A: 

As usual the answer is that it depends... By itself, no, VB.Net is not slower than C#, at least nothing that you will notice. Yes, there will be slight differences in compiler optimization, but IL generated will be essentially the same.

However, VB.Net comes with a compatibility library for programmers used to VB6. I am remembering about those string methods like left, right, mid, old VB programmers would expect. Those string manipulation functions are slower. I'm not sure you would notice an impact, but depending on the intensity of their use, I'd bet the answer would be yes. Why are those methods slower than "native" .net string methods? Because they are less type-safe. Basically, you can throw almost anything at them and they will try to do what you want them to, just like in old VB6.

I am thinking about string manipulation, but if I think harder, I'm sure I'll remember about more methods thrown into that compatibility layer (I don't remember the assembly's name, but remember it is referenced by default in VB.Net) that would have a performance impact if used instead of their .net "native" equivalent.

So, if you keep on programming like you were in VB6, then you might notice an impact. If not, it's ok.

Rui Craveiro
You're eright! The slowest app I've found is the one I'm developing now: It's slow not because of the language (VB), it's because it requests for data from a remote BD. The 1.5 seconds it needs to load its Form depends not on the app itself, it depends on how busy/old/crappy the server is.
yelinna
A: 

It is not really a myth. While C# and VB.Net both compile to IL, the actual instructions produced are likely to be different because 1. the compilers may have different optimisations and 2. the extra checks that VB.Net does by default e.g. arithmetic overflow. So in many cases the performance will be the same but in some cases C# will be faster. It's also possible VB.Net might be quicker in rare circumstances.

Matt Howells
It's not a surprise that you can configure VB.NET to be slower. But I assume the OP was asking, "with all else being equal, is VB.NET code slower than C#", and you haven't answered that. So, -1.
John Saunders
It's not a case of 'configuring VB.Net to be slower'. That is how it is configured out of the box, _by default_. So an awful lot of VB.Net code out there in the wild will be a bit slower than it would have been had it been written in C#. All else being equal, they are still two different compilers written by different teams.
Matt Howells
+2  A: 

It depends on what you're doing. I think there's no real difference between VB and C#. The both of them are .Net languages and they're compiled in IL.

More info? Read this:

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

yelinna
A: 

There are some small differences in the generated code that may make C# slightly faster in some situations. For example VB.NET has some extra code to clear the local variables in a method while C# doesn't.

However, those differences are barely measurable, and most code is so far from optimal that you are just starting in the wrong end by switching language to make the code run faster. You can take just about any CPU intensive code and rather easily make it twice as fast. Some code can be made 10 times faster, other code perhaps 10000 times faster. In that context the few percent that you may gain by using C# instead of VB.NET is not worth the effort.

On the other hand, learning C# may very well be an effective way of speeding up your code. Not because C# can produce faster code, but because you will get a better understanding of both C# and VB.NET, enabling you to write code that performs better in either language.

Edit:
The C# and VB.NET compilers are obviously developed more or less in sync. The speed difference between C# 1 and C# 2 is something like 30%, the difference between the parallel versions of C# and VB.NET is a lot less.

Guffa
A: 

yes, and yes. on both questions.

maxwellb
they both can't be true
Jader Dias
;-)
maxwellb
A: 

My understanding is instead of (in vb.net):

Method 1:

IF X = true Then  
     Y=1
END IF

Method 2:

IF X = TRUE THEN Y=1

Method 2 compliles more effecient MSIL

Darknight

Darknight
This is completely false.
SLaks