OMG VB.net more efficient than C#??

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I was viewing some strange behaviour in c# so I tried a
comparison in vb.net

A simple 1 line console application written in both c# and
vb.net (One line meaning one line in the main function).

Console.WriteLine(100L)

It appears vb.net declares a 8 byte long and stores the
value into it before calling the console.writeline method
which is what I would expect. However in c# it declares a
4 byte variable, and converts it to an 8 byte long,
wasting one extra instruction call.

Is this behaviour a bug in the framework or in fact vb.net
is more efficient at handling longs as apposed to c#.

The msil code for both programs is included below..

VB.net code ++++++++++++++++++++++++++++++++
..method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]
System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 15 (0xf)
.maxstack 8
IL_0000: ldc.i8 0x64
IL_0009: call void [mscorlib]
System.Console::WriteLine(int64)
IL_000e: ret
} // end of method Module1::Main

c# code ++++++++++++++++++++++++++++++++++++++++++++
..method private hidebysig static void Main(string[] args)
cil managed
{
.entrypoint
.custom instance void [mscorlib]
System.STAThreadAttribute::.ctor() = ( 01 00 00 00 )
// Code size 9 (0x9)
.maxstack 1
IL_0000: ldc.i4.s 100
IL_0002: conv.i8
IL_0003: call void [mscorlib]
System.Console::WriteLine(int64)
IL_0008: ret
} // end of method Class1::Main
 
Is this behaviour a bug in the framework or in fact vb.net
is more efficient at handling longs as apposed to c#.
Click to expand...

VB.NET isn'T better...
it makes no difference. don'T forget :that'S just immediate language.
It needs to be optimized by the jit compiler anyways.
and I'd say that the c# version will be better for optimizing:
..)the jit works with 32bit ints on the execution stack. -> pushing 4bytes
on it is faster than 8bytes -> c# compiler has noted that there is a value
small enough for int
..)converting on the execution stack to long is efficient. on a 64bit cpu
the JIT may translate to simply setting a flag. or even better when he sees
what is happening with that long he might decide some other optimization.
in the vb.net version he'S forced to work with 2 32bit slots on the
execution stack.

what's more interesting is that VB.NET reserves a maximum stack size of 8
items. imho that'S not necessary for such a simple function.
 
Back
Top