Why does activex control run 3x+ faster in vb5 than .net?

[bartj1]

Hi,

I did a benchmark comparison of a National Instruments Active-x "Strip
Chart" control in both Vb5 and vb.net(2005). The code is identical:

For I = 1 to 10000
ARR(1,0) = J
AxCWGraph1.ChartY(arr)
j = J + 1
If j 10 then j = 0
Next

It takes .8 seconds for a VB5 exe to run and 3 seconds for a .net exe
to run(same machine).

I realize that a .net component would be the better way to go instead
of using active-x in .net, but why the HUGE speed diff?

Thanks,
Bart

[Spam Catcher]

ba****@gmail.com wrote in news:1162249254.740872.138680
@e64g2000cwd.googlegroups.com:

It takes .8 seconds for a VB5 exe to run and 3 seconds for a .net exe
to run(same machine).

I realize that a .net component would be the better way to go instead
of using active-x in .net, but why the HUGE speed diff?

Could be due to a couple factors... ActiveX is not mananged code, so the
..NET runtime has to marshal all the calls. Marshaling calls use up extra
CPU cycles.

VB compiles native code while .NET does not. Native code tends to run
faster than non-native code. If speed is of the utmost importance, there
are tools on MSDN to compile .NET code into native code.

[Rich]

I am interested in getting the native compiler. DO you know where I can
download it from exactly? URL?
(I tried searching MSDN but turned up little.)
Spam Catcher wrote:

bartj1_gmail.com wrote in news:1162249254.740872.138680
_e64g2000cwd.googlegroups.com:

It takes .8 seconds for a VB5 exe to run and 3 seconds for a .net exe
to run(same machine).

I realize that a .net component would be the better way to go instead
of using active-x in .net, but why the HUGE speed diff?

Could be due to a couple factors... ActiveX is not mananged code, so the
.NET runtime has to marshal all the calls. Marshaling calls use up extra
CPU cycles.

VB compiles native code while .NET does not. Native code tends to run
faster than non-native code. If speed is of the utmost importance, there
are tools on MSDN to compile .NET code into native code.

[Robert]

>It takes .8 seconds for a VB5 exe to run and 3 seconds for a .net exe
to run(same machine).

I realize that a .net component would be the better way to go instead
of using active-x in .net, but why the HUGE speed diff?

Could be due to a couple factors... ActiveX is not mananged code, so the
.NET runtime has to marshal all the calls. Marshaling calls use up extra
CPU cycles.

VB compiles native code while .NET does not. Native code tends to run
faster than non-native code. If speed is of the utmost importance, there
are tools on MSDN to compile .NET code into native code.

This is WRONG. All .Net code is native code. There is NO INTERPRETER.
There never has been. I doubt there ever will be.

There is a JIT compiler. Just In Time *COMPILER". This compiles MSIL
into native code.

Please stop spreading erroneous "facts".
As to the original question, part of the speed problem may come from Visual
Studio. First try the app after doing a release build. Run the executable
directly.
It may be much faster.

If it is indeed faster, and you want a faster development environment, try
turning of some of the managed debugging assistant. I do some image
processing code from time to time, and calling into DLL's with MDA
checking the stack size before and after every call can be expensive.

[Chris Dunaway]

Spam Catcher wrote:

ba****@gmail.com wrote in news:1162249254.740872.138680
@e64g2000cwd.googlegroups.com:

It takes .8 seconds for a VB5 exe to run and 3 seconds for a .net exe
to run(same machine).

I realize that a .net component would be the better way to go instead
of using active-x in .net, but why the HUGE speed diff?

Could be due to a couple factors... ActiveX is not mananged code, so the
.NET runtime has to marshal all the calls. Marshaling calls use up extra
CPU cycles.

VB compiles native code while .NET does not. Native code tends to run
faster than non-native code. If speed is of the utmost importance, there
are tools on MSDN to compile .NET code into native code.

I believe that this is only partially correct. The compiler compiles
down to MSIL, but when the program is run the JIT compiler compiles
that to native code. But my understanding is that it does so as needed
(i.e. as methods are called, they are JIT compiled to native code).
Perhaps someone with more in depth knowledge than me can elaborate.

You can run ngen.exe on your .Net .exe to pre-compile them. You will
get faster startup times this way.

[Dick Grier]

Hi,

Part of the issue is data marshaling (as another reply mentioned). There is
a wrapper dll built by .NET to encapsulate the Ax control, so there also is
an extra layer of code there.

Make sure that you are running an EXE that was created in Release Mode.

Try the .NET controls from NI. They are managed code, so they should
execute faster.

My biggest question is why are you changing the strip chart INSIDE the loop?
Just create the data array in the loop and... Call AxCWGraph1.ChartY(arr)
after the array has been filled. You may notice something interesting.

Dick

--
Richard Grier, MVP
Hard & Software
Author of Visual Basic Programmer's Guide to Serial Communications, Fourth
Edition,
ISBN 1-890422-28-2 (391 pages, includes CD-ROM). July 2004, Revised March
2006.
See www.hardandsoftware.net for details and contact information.

[Spam Catcher]

"Robert" <[e-mail] in news:uS**************@TK2MSFTNGP05.phx.gbl:

>VB compiles native code while .NET does not. Native code tends to run
faster than non-native code. If speed is of the utmost importance, there
are tools on MSDN to compile .NET code into native code.

This is WRONG. All .Net code is native code. There is NO INTERPRETER.
There never has been. I doubt there ever will be.

There is a JIT compiler. Just In Time *COMPILER". This compiles MSIL
into native code.

Is MSIL native?

[Robert]

>>VB compiles native code while .NET does not. Native code tends to run
faster than non-native code. If speed is of the utmost importance, there
are tools on MSDN to compile .NET code into native code.

This is WRONG. All .Net code is native code. There is NO INTERPRETER.
There never has been. I doubt there ever will be.

There is a JIT compiler. Just In Time *COMPILER". This compiles MSIL
into native code.

Is MSIL native?

You may want to read up on it..

http://www.google.ca/search?client=o...utf-8&oe=utf-8

[Spam Catcher]

"Robert" <[e-mail] in
news:ec**************@TK2MSFTNGP03.phx.gbl:

>Is MSIL native?

You may want to read up on it..

http://www.google.ca/search?client=o...opera&ie=utf-8
&oe=utf-8

I know what MSIL is:

"During compilation of .NET programming languages, the source code is
translated into MSIL code rather than machine-specific object code. "

Hence non-native.

[Spam Catcher]

Spam Catcher <sp**********@rogers.comwrote in
news:Xn**********************************@127.0.0. 1:

"Robert" <[e-mail] in
news:ec**************@TK2MSFTNGP03.phx.gbl:

>>Is MSIL native?

You may want to read up on it..

http://www.google.ca/search?client=o...opera&ie=utf-8
&oe=utf-8

I know what MSIL is:

"During compilation of .NET programming languages, the source code is
translated into MSIL code rather than machine-specific object code. "

Hence non-native.

P.S. The article has a good picture:

http://en.wikipedia.org/wiki/Microso...diate_Language

[Robert]

>>>Is MSIL native?

You may want to read up on it..

http://www.google.ca/search?client=o...opera&ie=utf-8
&oe=utf-8

I know what MSIL is:

"During compilation of .NET programming languages, the source code is
translated into MSIL code rather than machine-specific object code. "

Hence non-native.

P.S. The article has a good picture:

http://en.wikipedia.org/wiki/Microso...diate_Language

Yes, I have a compiler targetting MSIL in my current project. Users
can enter equations in, with constants, app vars, properties, fields etc.
This is
used for data mining , visualisations, and a few reports. Beats having a
programmer
sit with them all day.. It's about 20 classes, and maybe 4-5000 lines of
code.
Nothing super huge, the parsing is probably half of it. The actual MSIL is
not so bad, if you can deal with stacks. I spent about 2 weeks on this.

Anway:

Funny how you trimmed your original post where you mentioned VB is compiled
but .net is not...

First, VB.Net is compiled, once to MSIL. Then it just sits there on disk.
Until you run it. Whether you run it via IDEor otherwise, IT IS JITTED
TO MACHINE CODE, THEN EXECUTED.

Without the JIT, it is a datafile, describing a program. It is not a
program.
It is meaningless to talk about "Not Compiled" with regard to .Net. There
is no other way for the code to run.

Do you claim that the JIT'er is not part of .Net?

Also, FYI, VB1-VB6 all had interpreters. VB5, and VB6 were the only ones
with
compilers, so saying VB was compiled, is technically, ummm, WRONG.
Further, the interpreter was good and small, and so were the dll's for your
prog.
For infrequently used code, on smaller/older boxes, intepreted was a PLUS.

Other than that, great thread.

HTH, HAND, love and kisses, etc.

[Spam Catcher]

"Robert" <[e-mail] in
news:uq**************@TK2MSFTNGP04.phx.gbl:

Funny how you trimmed your original post where you mentioned VB is
compiled but .net is not...

I did not say .NET does not compile code. I said .NET does not compile
NATIVE code.

Also, FYI, VB1-VB6 all had interpreters. VB5, and VB6 were the only
ones with
compilers, so saying VB was compiled, is technically, ummm, WRONG.

AFAIK, VB5 & 6 provided an option to compile code into native CPU code.
The OP was using VB5 hence I said VB was natively compiled in context of
VB5 (and the OP's project).

>Do you claim that the JIT'er is not part of .Net?

I never mentioned JIT in my original post. Native code and MSIL compiled
code is not the same thing - Native code can be more or less be directly
executed on the CPU while MSIL requires the extra step of going through
the JIT. Hence the code is not native.

So I don't get where I went wrong?

Anyways at the crux of our debate is whether or not .NET generates native
cpu code right? AFAIK, it generates MSIL NOT native CPU code.

Regardless of what you want to say - MSIL is NOT native code. Managed
..NET code perhaps - but definately NOT native code.

I don't get where I went wrong with that interpretation.

[Theo Verweij]

Spam Catcher wrote:

"Robert" <[e-mail] in
news:uq**************@TK2MSFTNGP04.phx.gbl:

>Funny how you trimmed your original post where you mentioned VB is
compiled but .net is not...

I did not say .NET does not compile code. I said .NET does not compile
NATIVE code.

True, it compiles MSIL, as mentioned tons of times in this thread.

>

>Also, FYI, VB1-VB6 all had interpreters. VB5, and VB6 were the only
ones with
compilers, so saying VB was compiled, is technically, ummm, WRONG.

AFAIK, VB5 & 6 provided an option to compile code into native CPU code.
The OP was using VB5 hence I said VB was natively compiled in context of
VB5 (and the OP's project).

The compile option of VB5 & 6 gave a max of 20% performance boost
compared to the interpreted versions. Looks like a good interpreter
works almost as fast as a bad compiler.

>

>Do you claim that the JIT'er is not part of .Net?

I never mentioned JIT in my original post. Native code and MSIL compiled
code is not the same thing - Native code can be more or less be directly
executed on the CPU while MSIL requires the extra step of gothrough
the JIT. Hence the code is not native.

So I don't get where I went wrong?

here: JIT compiling is the same as normal compiling. The only difference
is that with a "normal" compiler, the complete application is compiled
before it is run for the first time and with JIT compiling, a method is
compiled when it is first run. After a method has been JITted, it will
not be compiled again - it is native code.
So the only performance hit JIT is giving, is that the methods are
compiled at the first time they are called. All calls after this first
one do not have this performance hit.

Anyways at the crux of our debate is whether or not .NET generates native
cpu code right? AFAIK, it generates MSIL NOT native CPU code.

Regardless of what you want to say - MSIL is NOT native code. Managed
..NET code perhaps - but definately NOT native code.

I don't get where I went wrong with that interpretation.

You went wrong with the assumption that it doesn't run as native code.
There is never any MSIL executed. There is also no interpreter that
executes .net. There is only a just in time COMPILER that compiles the
code to NATIVE code at the moment that it is first needed.

[Spam Catcher]

Theo Verweij <tv******@xs4all.nlwrote in
news:#n**************@TK2MSFTNGP04.phx.gbl:

here: JIT compiling is the same as normal compiling. The only
difference is that with a "normal" compiler, the complete application
is compiled before it is run for the first time and with JIT
compiling, a method is compiled when it is first run. After a method
has been JITted, it will not be compiled again - it is native code.
So the only performance hit JIT is giving, is that the methods are
compiled at the first time they are called. All calls after this first
one do not have this performance hit.

Yes, but the JIT compiling needs to occur for each application run.

>Anyways at the crux of our debate is whether or not .NET generates
native cpu code right? AFAIK, it generates MSIL NOT native CPU code.

Regardless of what you want to say - MSIL is NOT native code. Managed
..NET code perhaps - but definately NOT native code.

I don't get where I went wrong with that interpretation.

You went wrong with the assumption that it doesn't run as native code.
There is never any MSIL executed. There is also no interpreter that
executes .net. There is only a just in time COMPILER that compiles the
code to NATIVE code at the moment that it is first needed.

What I've been saying is that the assembly on the disk is not native code
- it takes an extra step to get there. JIT inherently takes CPU cycles
(regardless of how efficent it is) so the JIT compiler could account for
some performance difference. If this were not the case, ngen would be a
moot tool huh?

[Robert]

>Anyways at the crux of our debate is whether or not .NET generates native
cpu code right? AFAIK, it generates MSIL NOT native CPU code. Regardless
of what you want to say - MSIL is NOT native code. Managed ..NET code
perhaps - but definately NOT native code.

I don't get where I went wrong with that interpretation.

You went wrong with the assumption that it doesn't run as native code.
There is never any MSIL executed. There is also no interpreter that
executes .net. There is only a just in time COMPILER that compiles the
code to NATIVE code at the moment that it is first needed.

To summarize and clarify:
1) VB.net code is produced by a programmer.
2) Visual Studio compiles this to MSIL
3) MSIL is JIT'ed into whatever supported instruction set.
4) Code is cached, then executed.

Your term ".Net" is too broad. As was MS's which wanted
"Every Product.Net" (tm) for a while. It lost all meaning and was
widely ridiculed.

..Net requires the use of at least two compilers before execution (unless
you are manually doing MSIL..) Both of these are part of .Net.
One without the other would be fairly useless as a development tool.

..Net is a platform. It has layers.

Native code is interpreted, too. Hard to load a DLL without interpreting
some parameters, paging in some code, etc. The OS is part of the stack,
too.
Something outside your code must make these decisions at runtime.

Further X86 has been interpreted into a RISC'ish set of internal
instructions
since the Pentium Pro.
For some really interesting reading on code analyzers and optimizers in
MSIL check out http://research.microsoft.com/phoenix/
and http://research.microsoft.com/phoenix/technical.aspx

Can't wait for this to get into production. Should give everything from
VC++
on up a nice speed boost. Compiler with optimizer plug-ins, anyone?
Maybe .Net 4.0. 3.0 seems incremental..

[Robert]

>
Yes, but the JIT compiling needs to occur for each application run.

No, only the first run. It is cached.

What I've been saying is that the assembly on the disk is not native code
- it takes an extra step to get there. JIT inherently takes CPU cycles
(regardless of how efficent it is) so the JIT compiler could account for
some performance difference. If this were not the case, ngen would be a
moot tool huh?

NGen is no panacea.

See the following
http://www.softinsight.com/bnoyes/Pe...e-3ffc0eada041

http://msdn.microsoft.com/msdnmag/is...n/default.aspx

[Theo Verweij]

You are right.

If vb.net was 2.2 secs slower than vb5, this means that the interop call
costs about 0.22 msec (10000 calls to the ocx method ChartY).

Dick Grier wrote:

Hi,

Part of the issue is data marshaling (as another reply mentioned). There is
a wrapper dll built by .NET to encapsulate the Ax control, so there also is
an extra layer of code there.

Make sure that you are running an EXE that was created in Release Mode.

Try the .NET controls from NI. They are managed code, so they should
execute faster.

My biggest question is why are you changing the strip chart INSIDE the loop?
Just create the data array in the loop and... Call AxCWGraph1.ChartY(arr)
after the array has been filled. You may notice something interesting.

Dick