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

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

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 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:
Show quoteHide quote

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.

Is MSIL native?

You may want to read up on it..

http://www.google.ca/search?client=opera&q=msil&sourceid=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 <spamhoneypot@rogers.com> wrote in
Show quoteHide quoteP.S. The article has a good picture:

http://en.wikipedia.org/wiki/Microsoft_Intermediate_Language

Show quote Hide quote 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.

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

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).

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.

Spam Catcher wrote:
True, it compiles MSIL, as mentioned tons of times in this thread.

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.

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.

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.

Theo Verweij <tverw***@xs4all.nl> wrote in
Yes, but the JIT compiling needs to occur for each application run.

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?

No, only the first run.  It is cached.

NGen is no panacea.

See the following
http://www.softinsight.com/bnoyes/PermaLink.aspx?guid=35d18c9e-f8cc-4f03-aa1e-3ffc0eada041

http://msdn.microsoft.com/msdnmag/issues/05/04/NGen/default.aspx

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..

Spam Catcher wrote:
Show quoteHide quoteI 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.

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

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:
Show quoteHide quote

IsNumeric question
Access dynamic controls by name?
How to turn off Managed Debugging Assistant in VB.NET (2005)
Format string in DataGrid
Multiple Component Classes
Messages
OT-develing on several machines
Multiple TcpListeners on the same IP address
Replacing Double quotes with TWO Single Quotes
Windows Service not starting automatically