Here are two old posts that might help ...

oooooooooooooooooooooooooooooooooo

Optimize for Fast Code
Maximizes the speed of compiled executable files by instructing the compiler
to favor speed over size.

When the compiler translates Visual Basic statements into machine code,
there are often many different sequences of machine code that can correctly
represent a given statement or construct. Sometimes these differences offer
trade-offs of size versus speed. Selecting this option ensures that when the
compiler recognizes such alternatives it will always generate the fastest
code sequence possible, even when that may increase the size of the compiled
program.


Optimize for Small Code

Minimizes the size of .exe and .dll files by telling the compiler to favor
size over speed.



No Optimizations

Turns off all optimizations.

With this option selected, the compiler generates code that is significantly
slower and larger than if optimization for fast or small code is selected.



Compiled vs. Interpreted Applications (aka native compile vs pcode compile)

By default, applications created in Visual Basic are compiled as interpreted
or p-code executables. At run time, the instructions in the executables are
translated or interpreted by a run-time dynamic-link library (DLL). The
Professional and Enterprise editions of Visual Basic include the option to
compile a native code .exe. In many cases, compiling to native code can
provide substantial gains in speed over the interpreted versions of the same
application; however, this is not always the case. The following are some
general guidelines regarding native-code compilation.

Code that does a lot of primitive operations on hard-typed, nonstring
variables will yield a maximum ratio of generated native code to displaced
p-code operations. Complex financial calculations or fractal generation,
therefore, would benefit from native code.

Computationally intensive programs, or programs that shuffle a lot of bits
and bytes around within local data structures, will gain very visibly with
native code.

For many programs, especially those doing a lot of Windows API calls, COM
method calls, and string manipulations, native code will not be much faster
than p-code.

Applications that consist primarily of functions from the Visual Basic for
Applications run-time library are not going to see much if any advantage
from native code, because the code in the Visual Basic for Applications
run-time library is already highly optimized.

Code that involves a lot of subroutine calls relative to inline procedures
is also unlikely to appear much faster with native code. This is because all
the work of setting up stack frames, initializing variables, and cleaning up
on exit takes the same time with both the p-code engine and generated native
code.

Note that any calls to objects, DLLs or Visual Basic for Applications
run-time functions will negate the performance benefits of native code. This
is because relatively little time is spent executing code - the majority of
time (usually around 90-95%) is spent inside forms, data objects, Windows
..dlls, or the Visual Basic for Applications run time, including intrinsic
string and variant handling.

In real-world tests, client applications typically spent about 5% of their
total execution time executing the p-code. Hence, if native code was
instantaneous, using native code for these programs would provide at most a
5% performance improvement.

What native code does is to enable programmers to write snippets of code or
computationally intensive algorithms in Basic that were never possible
before because of performance issues. Enabling these "snippets" to run much
faster can also improve the responsiveness of certain portions of an
application, which improves the perceived performance of the overall
application.


oooooooooooooooooooooooooooooooooo

From what I've seen for VB6, pCode results in a MUCH smaller exe, runs
faster, and avoids an error some have reported that is totally
unreproducible on other systems. It seems the optimizing compiler can cause
evaluations of complex statements to occur out of order, generating an
untrappable Divide by 0 error.

For example, someone wrote to me about what
appeared to be an error in the code:

'the call
  sHiByte = CStr(HiByte(WSAD.wVersion))
  (WSAD.wVersion had a value of 257)

Public Function HiByte(ByVal wParam As Integer) As Integer

   HiByte = (wParam \ &H100) And &HFF

End Function

The functions should have evaluated the wParam \ &H100  (257 \ 256 = 1) and
then And the result with 255 (resulting in 1).  On my system the code, as a
native compile exe did exactly that. But on the problem system, his exe
always generated the divide by 0 error and a MsgBox confirmed this was the
offending line. In addition, his exe on my system also generated the error.

No amount of tweaking of the function could resolve his problem ... ie this
still failed ..

Public Function HiByte(ByVal wParam As Integer) As Integer

   Dim tmp as Integer
   tmp = wParam \ &H100
   HiByte = tmp And &HFF&

End Function

...which it clearly should not, given the value passed as wParam was correct.
I could only speculate that the compiler even here was resolving the
function into what it thought was a optimized version, and recreating the
error.

AFAIAK, its not worth the hassle. I stick to pCode.


-- 


Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/


"Dino"  wrote in message 
news:4DGsd.775$%S3.124361{at}read2.cgocable.net...
: Hi All, thanks in advance to all for assisting me on this question:
:
: I have an application that will compile in P-Code but not in Native Code!
:
: my question I guess is what is the difference.  I am sure I have always
: compiled in Native Code but now as I go to compile I get a stoppage and 
when
: I go to my task manager, sure enough it is showing (Not Responding)  when 
I
: change how to compile in the properties to P-Code it not only compiles
: quicker then it ever has, but it does not freeze on me!
:
: What is the difference?  If I compile in P-Code will my application still
: run on other machines ok?
:
: thanks in advance!
:
: Michael Lortie, PS
: MTC Software Solutions
: Creating Affordable Solutions
:
:
---
þ RIMEGate(tm)/RGXPost V1.14 at BBSWORLD * Info{at}bbsworld.com

---
 * RIMEGate(tm)V10.2áÿ* RelayNet(tm) NNTP Gateway * MoonDog BBS
 * RgateImp.MoonDog.BBS at 12/5/04 4:39:31 PM