C# or VB.NET - not exaclty the same performance

  • Thread starter Thread starter Daniel P.
  • Start date Start date
Well, it's been a while since I did this, and I attempted a line for line
translation. I didn't use Option Strict (don't even think I knew about
that at the time), and there were no try..catch statements in the
original C# files, so no, there is no error handling. It's a short little
thing, but the AI routines execute thousands of times so that there is
a noticeable lag even with the C# version. The VB version, however
lags painfully. Like I said, just email me if you want a copy, then you
can play around with it yourself.

The thing that prompted me to do this was an article I read somewhere
about the way the compilers optimize. I've also done this to quite a
few small progs, just to look at the IL generated from ILDASM. I was
surprised to see how horrible some of the dissassembled VB exes
looked, sometimes there were NOP's scattered about for no apparent
reason. I'm no expert, but after that experiment I knew C# was going
to be my .NET language of choice!
 
Well without Option Strict, it's not even a fair comparison between VB.NET
and C#. Leaving Option Strict off allows VB to be a type-unsafe language,
and therefore it must make heavy use of reflection during runtime to execute
every line of code. Something as simple as an assignment statement can
potentially become several instructions.

Leaving Option Strict off also allows for late-binding, so VB may not even
bother to make sure certain methods exist at compile time, and may acutally
use reflection to look up the methods at run-time.

I too chose C# over VB, but it wasn't because of performance. When I do use
VB.NET, I make sure to always use Option Strict, and I never use any of VB's
runtime functions, instead using the .NET framework classes themselves.

--Matthew W. Jackson
 
As small as this was, I never considered things like that, but I may
be missing something important. I'm sure to note this and probably
will do some more experiments now.

Thanks.
 
Hi Matthews,

Just a note, some so called old "Microsoft functions" are twice as fast as
some of the "modern" Net methods.

I think that it is because they mostly have less posibilities than the
methods.

In my opinion the benefit will be only noticable if it are functions used
more than 100.000 times in a minute or so.

I do not like them because that they use the 1 index. And I am used because
of the historical false start to use the zero.

As I said, just a note.

Cor
 
CJ,

No offense taken, and you have some very valid points. The only reason
I posted what I did was because the OP stated that identical programs in VB
and C# would produce the same IL, and the purpose of my example was to show
that was not the case. Yes, they are minor, but they support the idea that
VB and C# do not produce the same IL for similar operations. A larger
example would produce more differences, and that can be produced, if
desired.

Of course, one could argue that yes, the syntax of the IL that C#
generates is the same as the IL that VB generates (there is not a C# flavor
of IL, separate from a VB flavor of IL), meaning, they both have to generate
IL that adheres to a standard, so in that sense, the IL that they output the
same IL, but I doubt that is what the OP intended.

As for performance numbers (which is outside the scope of the original
thread subject) and its effect over time, well, yes, there can be an effect.
Just how much is dependent on the program itself. However, I agree with
you, it most likely will not be anything to lose sleep over.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

CJ Taylor said:
Nicholas,

Ok, so you showed a difference with using a single line code. I can see now
that there are slight differences in the IL, but nothing I'm going to lose
sleep over.

Second, Cor wasn't focusing on the identical attributes between IL, but the
fact that the VB Program used VB6 methods whereas C# used the Stream Reader,
thats a valid point right tthere (in my prevous point I had never seen the
source code to any of the programs, still haven't).

You show two what are seemingly minor differences. I know Jon Skeet points
out that this could change performance over time, but my question is, how
much? And then, with that amount, is that within tolerable limits?

Now, I'll admit, I am very engrossed with the way .NET works and how it all
compiles down to the IDL. But then, I think why I program .NET, because I'm
trying to get the job done (usually for business intelligence) in the
shortest amount of time possible. If I was that concerned over the
difference of 8 clock cycles in an operation in my program, I would have
written it in assembly.

I just don't think showing a stack initializer with a very small difference
and an extra attribute in the constructor really proves anything. But, I
didn't nor do I program compilers... Hell, this could be like using a long
to store a short value.

None of this was meant to be offensive.

-CJ

message news:[email protected]...
Cor,

The following C# code:

using System;
namespace ConsoleApplication22
{
class Class1
{
[STAThread]
public static void Main(string[] args)
{
Console.WriteLine("Hello there");
}
}
}

Compiles to the following IL:

.method public hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 11 (0xb)
.maxstack 1
IL_0000: ldstr "Hello there"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: ret
} // end of method Class1::Main

The following VB code:

Public Class Class1
Public Shared Sub Main(ByVal args As String())
Console.WriteLine("Hello there")
End Sub
End Class

Compiles to the following IL:

.method public static void Main(string[] args) cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01
00 00 00 )
// Code size 11 (0xb)
.maxstack 8
IL_0000: ldstr "Hello there"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: ret
} // end of method Class1::Main

Notice the differences. Specifically:

- The difference in the declaration for Main
- The difference in the maxstack.

And that is just one line of code.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Cor said:
Hi Nicholas,

You don't need samples. You can just take two simple programs,
Click to expand...
one
in
VB and one in C#, and then compile them. Then, use ILDASM to view
Click to expand...
the
IL.
You will see differences in it.

That is as you said it in the syntax not in the context

If they did, then they were misinformed, as the tools
definitely will produce different IL.

But forget it we always makes sometimes mistakes

:-)

Cor
Click to expand...
Click to expand...
Click to expand...
 
Hey Nicholas,


Nicholas Paldino said:
CJ,

No offense taken, and you have some very valid points. The only reason
I posted what I did was because the OP stated that identical programs in VB
and C# would produce the same IL, and the purpose of my example was to show
that was not the case. Yes, they are minor, but they support the idea that
VB and C# do not produce the same IL for similar operations. A larger
example would produce more differences, and that can be produced, if
desired.
Click to expand...

I know a few others marked how the larger the program got the more it became
different in the IL. I know Tom and a few others brought up the typecasting
issue (C# has better typecasting then VB) which I could see, but the option
strict tests showed this wasn't really the case.

I think I find emotion in this because I believed for so long (and told
others even on here) that all the .NET languages produced the same IL.
Mmm.. this is where words get fun. Does it produce the same language?
Yep... Are they identical. as you and others have seen nope. So I feel a
little thwarted as well as pretty dumb that I fell into a word trap with
Microsoft. =)

Yeah they are close, as expected, I guess this just gives the c++/c#
programmers more reason to show there "ultimate superiority". Oh well, at
least VB programmers can get laid... =)

Of course, one could argue that yes, the syntax of the IL that C#
generates is the same as the IL that VB generates (there is not a C# flavor
of IL, separate from a VB flavor of IL), meaning, they both have to generate
IL that adheres to a standard, so in that sense, the IL that they output the
same IL, but I doubt that is what the OP intended.
Click to expand...

Yeah I definatly think the op was going more on the standpoint that they had
two different code doms producing the IL. But I can't imagine what it would
take to write a compiler, well I could, just don't want to, and to make them
syntatically identical would be nearly impossible giving the difference in
structure between the two languages...

I was reading the comparison chart between all the languages, and I started
thinking about little things that make them different. For example, VB is
the only language to have the With statement. this is one of those issues
that cuold cause different behavior in the IL. Same with Redim. (maybe not
as much, but who knows).

So, I think my question would be, is it fair to compare the languages syntax
in the IL since they are not syntacially identical? Going back to the
apples-to-apples idea that has been brought up so much in this thread.
maybe it isn't just the statements we are using, maybe its the fact that
each language has its own features, and that could utlimatly result in the
different IL generation.

Nonetheless... I think his performance tests were crap...


As for performance numbers (which is outside the scope of the original
thread subject) and its effect over time, well, yes, there can be an effect.
Just how much is dependent on the program itself. However, I agree with
you, it most likely will not be anything to lose sleep over.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

CJ Taylor said:
Nicholas,

Ok, so you showed a difference with using a single line code. I can see now
that there are slight differences in the IL, but nothing I'm going to lose
sleep over.

Second, Cor wasn't focusing on the identical attributes between IL, but the
fact that the VB Program used VB6 methods whereas C# used the Stream Reader,
thats a valid point right tthere (in my prevous point I had never seen the
source code to any of the programs, still haven't).

You show two what are seemingly minor differences. I know Jon Skeet points
out that this could change performance over time, but my question is, how
much? And then, with that amount, is that within tolerable limits?

Now, I'll admit, I am very engrossed with the way .NET works and how it all
compiles down to the IDL. But then, I think why I program .NET, because I'm
trying to get the job done (usually for business intelligence) in the
shortest amount of time possible. If I was that concerned over the
difference of 8 clock cycles in an operation in my program, I would have
written it in assembly.

I just don't think showing a stack initializer with a very small difference
and an extra attribute in the constructor really proves anything. But, I
didn't nor do I program compilers... Hell, this could be like using a long
to store a short value.

None of this was meant to be offensive.

-CJ

message news:[email protected]...
Cor,

The following C# code:

using System;
namespace ConsoleApplication22
{
class Class1
{
[STAThread]
public static void Main(string[] args)
{
Console.WriteLine("Hello there");
}
}
}

Compiles to the following IL:

.method public hidebysig static void Main(string[] args) cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() =
Click to expand...
(
01
00 00 00 )
// Code size 11 (0xb)
.maxstack 1
IL_0000: ldstr "Hello there"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: ret
} // end of method Class1::Main

The following VB code:

Public Class Class1
Public Shared Sub Main(ByVal args As String())
Console.WriteLine("Hello there")
End Sub
End Class

Compiles to the following IL:

.method public static void Main(string[] args) cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThreadAttribute::.ctor() =
Click to expand...
(
01
00 00 00 )
// Code size 11 (0xb)
.maxstack 8
IL_0000: ldstr "Hello there"
IL_0005: call void [mscorlib]System.Console::WriteLine(string)
IL_000a: ret
} // end of method Class1::Main

Notice the differences. Specifically:

- The difference in the declaration for Main
- The difference in the maxstack.

And that is just one line of code.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

Hi Nicholas,

You don't need samples. You can just take two simple
Click to expand...
programs,
one
in
VB and one in C#, and then compile them. Then, use ILDASM to view the
IL.
You will see differences in it.

That is as you said it in the syntax not in the context

If they did, then they were misinformed, as the tools
definitely will produce different IL.

But forget it we always makes sometimes mistakes

:-)

Cor
Click to expand...
Click to expand...
Click to expand...
 
Back
Top