Why to use native code compilation?

I'm developing VB5 app's.
Don't interest me the debugging features.
When I compile to native code, the EXE is of 1,2 MB. When I compile to pcode the EXE it is of 720 KB. I don't notice differences in the performance.
Why to use native code compilation?
Are the optimization switchs useful in the real life?

Thank you for their help
Who is Participating?
Thanks for your pts.
I measured 9 sec. for p-code, 1.5 sec for full optimization. P120/64MB
If you are doing any mathematics, you will see great difference.
If you are using arrays, removing bounds check will make your app fly.
If you switch on "Assume no aliasing", your loops will be faster.

Of course, wrong usage can couse GPF.
CarlosJacAuthor Commented:

Thank you for your answer. I reject your answer to give place to the opinion of other experts.
Keeping in mind what you say, the optimization switches don't seem to be very useful .

If I switch on "Assume no aliasing", my loops will be faster, but my app use ByRef ...

If I remove bounds check will make my app fly, but I can 've problems with my existent code ...
What cautions should I take to avoid the problems that I can suffer having this switch on?

I hope you understand me. My English is very poor.



Cloud Class® Course: Python 3 Fundamentals

This course will teach participants about installing and configuring Python, syntax, importing, statements, types, strings, booleans, files, lists, tuples, comprehensions, functions, and classes.

As a general rule, I don't use any optimizations as I have found that they tend to cause crashes - especially when the compiled programs are used on NT systems.  However, one "optimization" I will never use is compiling to Pcode, because it's simply a method of maintaining compatibility for vb 3 as vb3 compiled its programs to pcode.
CarlosJacAuthor Commented:

Thank you for your answer, but Why to use native code compilation if I don't notice differences in the performance, and the code size is doubled?


>"Assume no aliasing", my loops will be faster, but my app use ByRef ...
This option has nothing to do with using ByRef.
It allows using processor registers.
I don't wan't you to have troubles, so better you don't use optimization or don't blame me, when you will have troubles.

To use it:
1. You must be experienced, prepared for problems, or have a lot of E-E points :)
2. You must have a need for optimization:
E.g. you see an utility to do something (e.g. process a file).
You create the same thing, but much, much nicer and better user interface.
The util costs $10, so your should be say $15.
Then you try processing 1MB file and find it needs 20 seconds (the ugly one needs 1 second).
This is the situation for optimization.
CarlosJacAuthor Commented:
ameba: Again, thank you

Looks at what the vb books online says about asume no aliasing:

Using this option allows the compiler to apply optimizations it couldn't otherwise use, such as storing variables in registers and performing loop optimizations. However, you should be careful not to check this option if your program passes arguments ByRef, since the optimizations could cause the program to execute incorrectly.


I am very grateful for your help. I don't have anything to blame you

I would like you to see the difference in speed.
Start new project, add command button, paste this code to your form:
Option Explicit
Private myArray() As Double
Private Declare Function GetTickCount Lib "kernel32" () As Long

Private Sub Command1_Click()
    Dim i As Long, j As Long, numtests As Integer, tim0 As Long
    Dim max As Long
    max = UBound(myArray)
    numtests = 10
    tim0 = GetTickCount ' start timing
    ' our loop
    For j = 1 To numtests
        For i = 1 To max
            myArray(i) = myArray(i) + 0.5
    ' report time
    Caption = (GetTickCount - tim0) / 1000
End Sub

Private Sub Form_Load()
    ReDim myArray(1 To 500000)
End Sub

Private Sub Form_Unload(Cancel As Integer)
    Erase myArray ' free memory
End Sub

Please, make 2 exe:
1. P-code (Project1.Exe)
2. Fast optimization, with first 4 adv. options On (Project2.Exe)

Tell me what you measured.
ameba wrote about 'asume no aliasing'
>>>but my app use ByRef
>>This option has nothing to do with using ByRef

Hey, read carefully. It doesn't say:
"This occurs when using ByRef arguments."
It says:
"This occurs when using ByRef arguments that refer to the same ..."

CarlosJacAuthor Commented:

Put your comment as a answer.  The points are yours.
Thank you
Tell me what you measured
Carlos: las diferencias de tamaño dependen del modo de compilacion, porque se puede generar un .EXE con TODO lo que necesita en su interior, y, por otro lado, se puede generar un .EXE que solo contiene referencias a rutinas contenidas en archivos .DLL que se suponen ya existentes en la maquina donde se va a ejecutar. Debido a eso, el primero es mucho mayor que el segundo.


Carlos: size differences depend on the way you compile, 'cause you can generate a .EXE, with ALL it needs into it, and, on the other hand, you can create a .EXE which only has references to routines stored at .DLL files, which it's suposed they already exist at the machine where app. will be executed. Due to that, the former is much bigger than the last one.
CarlosJacAuthor Commented:
Here's my measures (Pentium 200, 64 MB RAM).

Pcode compilation: 6.649
Native: 1.96
Native with switch 1:      1.913
Native with switch 2:      1.425
Native with switchs 1,2:     1.371
Native with switchs 1,2,6:    0.941
Native with switchs 1,2,3,4:   1.097


Creo que hay un error en lo que dices.  Te estás refiriendo a linking estático vs linking dinámico.
No, Carlos; no estoy hablando de eso. Pero bueno, eso fue solo un comentario; olvidalo nomas...

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.