[ACCEPTED]-Is C# code faster than Visual Basic.NET code?-vb.net
That is a myth. They compile down to the 8 same CLR. However the compiler for the 7 same routine may come out slightly differently 6 in the CLR. So for certain routines some 5 may be slightly better like (0.0000001%) faster 4 in C# and vice versa for VB.NET, but they 3 are both running off the same common runtime 2 so they both are the same in performance 1 where it counts.
The only reason that the same code in vb.Net 34 might be slower than c# is that VB defaults to have
checked arithmetic on and c# doesn't.
By default, arithmetic 33 operations and overflows in Visual Basic 32 are checked; in c#, they are not.
If you 31 disable that then the resulting IL is likely 30 to be identical. To test this take your 29 code and run it through Reflector and you 28 will see that it looks very similar if you 27 switch from c# to vb.Net views.
It is possible 26 that an optimization (or just difference 25 in behaviour) in the c# compiler verses 24 the vb.net compiler might lead to one slightly 23 favouring the other. This is:
- Unlikely to be significant
- if it was it would be low hanging fruit to fix
- 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 22 few constructs in c# not in vb.net such 21 as unsafe pointers. Where used they might 20 provide some benefits but only if they were 19 actually used, and used properly. If you 18 are down to that sort of optimization you 17 should be benchmarking appropriately.
Frankly 16 if it makes a really big difference then the question 15 should not be "Which of c#/vb.net should 14 I use" you should instead be asking 13 yourself why you don't move some code over 12 to C++/CLI.
The only way I could think of 11 that the different compilers could introduce 10 serious, pervasive differences is if one 9 chose to:
- Implement tail calls in different places
- These can make things faster or slower and certainly would affect things on deeply recursive functions. The 4.0 JIT compiler on all platforms will now respect all tail call instructions even if it has to do a lot of work to achieve it.
- 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.
- 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 8 currently leave such optimization complexities 7 as en-registering of variables, calling 6 conventions, inlining and unrolling entirely 5 up to the common JIT compiler in the CLR. This 4 is likely to have far more of an impact 3 on anything else (especially when the 32 2 bit and 64bit JIT's can now behave quite 1 differently).
The framework is written in C# but that 15 still does not tell about performance differences 14 between C# or VB as everything is compiled to IL language which then actually 13 executed (including JITted and so on).
The 12 responsibility is on each specific language 11 compiler that what kind of IL they produce 10 based on source code. If other compiler 9 produces better suited IL than other, then 8 it could have performance difference. I 7 don't know exactly that is there this kind 6 of areas where they would cause drastically 5 different IL, but I doubt the differences 4 would still be huge.
Other aspect is completely 3 then the C#'s ability to run unsafe code 2 like using raw pointers etc that can give 1 performance on special scenarios.
There might be a slight difference in the 11 compiler optimization, but I'd say there 10 is no noticeable difference. Both C# and 9 VB.NET compile to Common Intermediate Language. In some cases, you may 8 be able to get a significant performance 7 gain in C# by using unsafe code, but under most circumstances 6 I wouldn't recommend doing so. If you need 5 something that performance critical, you 4 shouldn't use C# either.
The myth probably 3 started because of the huge difference in Visual 2 Basic 6 performance compared to the average 1 C++ application.
I was at a Microsoft conference and the 10 MS employees stated that C# is up to 8% faster 9 than VB.NET. So if this is a myth, it was 8 started by the people that work at MS. If 7 I can find the slides that state this I 6 would post them, but this was when C# just 5 came out. I think that even if it was true 4 at one point in time, that the only reason 3 for one to be faster than the other is how 2 things are configured by default like ShuggyCoUk 1 said.
It depends on what you're doing. I think 4 there's no real difference between VB and 3 C#. The both of them are .Net languages 2 and they're compiled in IL.
More info? Read 1 this:
As usual the answer is that it depends... By 27 itself, no, VB.Net is not slower than C#, at 26 least nothing that you will notice. Yes, there 25 will be slight differences in compiler optimization, but 24 IL generated will be essentially the same.
However, VB.Net 23 comes with a compatibility library for programmers 22 used to VB6. I am remembering about those 21 string methods like left, right, mid, old 20 VB programmers would expect. Those string 19 manipulation functions are slower. I'm not 18 sure you would notice an impact, but depending 17 on the intensity of their use, I'd bet the 16 answer would be yes. Why are those methods 15 slower than "native" .net string methods? Because 14 they are less type-safe. Basically, you 13 can throw almost anything at them and they 12 will try to do what you want them to, just 11 like in old VB6.
I am thinking about string 10 manipulation, but if I think harder, I'm 9 sure I'll remember about more methods thrown 8 into that compatibility layer (I don't remember 7 the assembly's name, but remember it is 6 referenced by default in VB.Net) that would 5 have a performance impact if used instead 4 of their .net "native" equivalent.
So, if 3 you keep on programming like you were in 2 VB6, then you might notice an impact. If 1 not, it's ok.
It is not really a myth. While C# and VB.Net 9 both compile to IL, the actual instructions 8 produced are likely to be different because 7 1. the compilers may have different optimisations 6 and 2. the extra checks that VB.Net does 5 by default e.g. arithmetic overflow. So 4 in many cases the performance will be the 3 same but in some cases C# will be faster. It's 2 also possible VB.Net might be quicker in 1 rare circumstances.
There are some small differences in the 26 generated code that may make C# slightly 25 faster in some situations. For example VB.NET 24 has some extra code to clear the local variables 23 in a method while C# doesn't.
However, those 22 differences are barely measurable, and most 21 code is so far from optimal that you are 20 just starting in the wrong end by switching 19 language to make the code run faster. You 18 can take just about any CPU intensive code 17 and rather easily make it twice as fast. Some 16 code can be made 10 times faster, other 15 code perhaps 10000 times faster. In that 14 context the few percent that you may gain 13 by using C# instead of VB.NET is not worth 12 the effort.
On the other hand, learning C# may 11 very well be an effective way of speeding 10 up your code. Not because C# can produce 9 faster code, but because you will get a 8 better understanding of both C# and VB.NET, enabling 7 you to write code that performs better in 6 either language.
The C# and VB.NET 5 compilers are obviously developed more or 4 less in sync. The speed difference between 3 C# 1 and C# 2 is something like 30%, the 2 difference between the parallel versions 1 of C# and VB.NET is a lot less.
C# and VB.Net are both compiled by IL. Also 19 C++ and F# are compiled by it. In fact, the 18 four languages I mentioned are executed 17 at the same speed. There isn't in these 16 "a faster language": the unique difference 15 is between auto garbage-collected languages 14 (C#, VB.Net, F# etc.) and those aren't auto-collected 13 (such as C++). This second group generally 12 is slower, because rarely the developer 11 know how and when collect the garbage in 10 the heap memory, however, if you are informed 9 about the heap memory, the program could 8 result faster if in C++. Hard graphics programs 7 are usually made in C++ (such as the most 6 of Adobe programs). You can also manually 5 collect the garbage in C# (
System.GC.Collect();) and in VB.Net 4 (
I know this answer is not fully inherent 3 to the question, but I want to offer you 2 many ways and choices. You choose the right 1 way for your programs.
More Related questions