VB and C# are similar? let's give a look...

  • Thread starter Thread starter Gianco
  • Start date Start date
G

Gianco

Can someone explain me why when I execute the VB code (on a smart
device, windows ce 4) VB 'thinks' about 130 secs and C# about 4
seconds?

In VB:
------

Dim i As Double

Dim a As Double
Dim b As Double
Dim x As Integer

Dim s1 As Integer
Dim s2 As Integer

s1 = System.Environment.TickCount

a = 6
b = 3
For i = 1 To 600000
x = (a * i) + 3.89 + (b * i)
Next

s2 = System.Environment.TickCount

MessageBox.Show((s2 - s1).ToString())

In C#:
------
double i;

double a;
double b;
int x;

int s1;
int s2;

s1 = System.Environment.TickCount;

a = 6;
b = 3;
for (i = 1; i <= 600000; ++i)
{
x = (int)((a * i) + 3.89 + (b * i));
}

s2 = System.Environment.TickCount;

MessageBox.Show((s2 - s1).ToString());

Gianco
 
C# Pooooooooooooooooowwwwwweeeeeeeeeeeer !!!!!
That has been long since I last told it :)

I'm not sure, but I believe that VB has all feature of playschool language
like weakly typed and uh.... and stuff like that.

Therefore I guess (I suppose) that when you wrote: "For i = 1 To 600000"
you had kind of 600000 extra box/unbox(cast)/box/unbox(cast) operation.
which are costly operation ...
 
Gianco,
What I would suggest, is after you compile both programs to use ILDASM.EXE
to look at the generated IL.

Looking at just the IL for your VB.NET code, part of it is your "i as
Double", the For Loop is calling a VB.NET runtime function to check for the
end of the loop.

Changing just "i as Double" to "i as Integer" your code went from 120 to 90
on my machine.

Hope this helps
Jay
 
Keep in mind that VB projects in Debug builds by default have runtime checks
enabled, which negatively affects short tight loops performance. On top of
that debug VB builds have extra nop instructions that add to execution time.
I expect that if you run your tests in Release mode, the results will be
nearly the same
 
Yes, I defined

Option Strict On
and
Option Explict On

but this causes only an error when I compile the code, I can solve it
using a CInt() function, but is slower!!!

VB could be a playschool language but the result is not funny...
 
I wrote this code just to test the performances of both languages
using doubles. In the reality I'm writing a class in VB that display
graphs, it uses only integers except when the graph points must be
scaled, they are multiplied to a scale factor (double) and this causes
a very slow 'thinking' process. The result is unacceptable... I
started to use VB only since few weeks so I'm seriously thinking to
rewrite everything in C# to avoid other surprises in the future...
What makes me laugh is that Microsoft slogans are 'code reusability'
and 'money savings' but now I must explain to my boss that I must redo
my project from start because the speed of VB is not acceptable...
result:

Code reusability = 0
Money saving = -10
Problems with my boss = 10

Thanks for the replies
Gianco
 
While definitely approving of the idea of moving to C#, I would suggest
nevertheless to open project properties and under Configuration
Properties/Optimization check the box "Remove Integer Overflow Checks". See
if it improves the performance.
 
What makes me laugh is that Microsoft slogans are 'code reusability'
and 'money savings' but now I must explain to my boss that I must redo
my project from start because the speed of VB is not acceptable...

you won't have to "redo from start" because you allready have the
code-logic!
All you have to do is to convert the syntax - and you must agree that the
overall work-flow is the same for VB.Net and C#.Net

So i would simply copy function by function into a C# project, edit the
syntax, compile (to check the syntax) and go on with the next function...
Of course it takes time... but not as much as starting from scratch.

Oh - and you could build assamblies from the VB.Net to reuse some routines
in C# without rewriting them...
result:

Code reusability = 0
+5

Money saving = -10
-5

Problems with my boss = 10

maybe a 2? ;-)
or maybe a 0 if you show him: "hey look how good our VB-Tool is... you know
PocketPC are not that fast... but hey - i've looked at C# in my spare time
and worked till midnight just to get THIS speed <show it> - i would say we
should switch to C# - takes us 3 more days but look <show it again>" :-)

Boris
 
Hello Alex

Yes I tried it but nothing of substantial happens. I tried also to
remove the debug informations from the code but is approximately the
same. I've seen the assembly code of both C# and VB codes and the
biggest difference is that VB operates a call to
System.Math::Round(float64) routine that probably is "fast" as a snail

Thanks however
Gianco
 
Hello Boris

Thank you for your suggestions, expecially the ones regarding the
things I must tell to my boss. I'll try.... If you will not see me
again in the forum, it means that he fired me ;-)

Bye
Gianco
 
LOL ... OK, then give me your boss' adress - maybe i know someone for the
job to fill in ;-)

No, i'm sure you will get it!

Oh, and BTW: take a look at http://msdn.microsoft.com/chats/ when the next
CompactFramework or VB.Net Chat will start.
I joined a chat yesterday and they are very responsive.

Boris
 
Back
Top