Library tutorials & articles
Performance Issues
Compiling
The release of VB5 at last gave VB programmers a chance to compile their VB applications to Native code. When you compile your VB project, and decide whether to compile as Native or P-code, and Fast or Small, there are a number of things to consider. To change any of these settings of your program, click the Compile tab on the project properties dialog.
The first is speed. How important this is depends on the type of program you are writing. Below is some results on a PIII 500Mhz, using the code below as the 'stuff to do'.
For I = 0 To 1000000 Step 0.1
A = Sqr(I) + A
z = A / 32.34
Next
| Compile Mode | Time Taken |
| Native Code - Fast Code | 8.077 |
| Native Code - Small Code | 9.1745 |
| Native Code - Fast Code (Favour Pentium) | 8.7876 |
| Native Code - Small Code (Favour Pentium) | 8.9505 |
| Native Code - No Optimization | 9.4461 |
| P-Code | 9.5598 |
| Run-time | 10.0695 |
As you can see, P-code is significantly slower than when compiling to Native Code.
The other is size. When you are distributing your program using CD-rom, this is not very significant. However, if you are making your program available over the internet, things are different. Below is the different sizes of my Developers Pad program when compiled in the different modes.
| Compile Mode | Size |
| Native Code - Fast Code | 816KB |
| Native Code - Small Code | 772KB |
| Native Code - No Optimization | 876KB |
| P-Code | 472KB |
As you can see, P-code is also significantly smaller than when compiling to Native Code. What you will have to decide on, is which mode you want to use. This will all depend on how you are distributing your program, and how important speed actually is. For simple things such as a Word processor, speed would not be very important (unless you perform a large amount of processing as the user is typing), and you may opt for the smaller executable file.
It is also worth noting that compiling to P-code is much, much quicker than compiling to Native code.
*** If you want to detect as many possible errors without compiling, start your program by pressing Ctrl+F5 instead of F5, as this will compile your program fully. You can also do this by unchecking compile on demand in the options dialog. Thanks to Magik for pointing this out to me. You can visit his website @ magikweb.cjb.net ***
Related articles
Related discussion
-
VB6 Runtime error 381 subsript out of range Error
by Uncle (2 replies)
-
passing and reading parameters from using Shell
by jigartoliya (0 replies)
-
Convert C++ code to VB6
by mawcot (4 replies)
-
listbox scrollbar
by Dennijr (10 replies)
-
Can you describe Above simple VB6 code?
by pramodmca09 (0 replies)
Related podcasts
-
Christian Beauclair
14 mai 2008 (�mission #0074) ::.Christian Beauclair: Stratégies de migration VB6 vers .NET Nous discutons avec Christian Beauclair des stratégies de migration VB6 vers .NET. Entre autres, nous discutons comment utiliser le "VB 6 Code Advisor" et le "Interop Forms Toolkit" pour ajouter la puiss...
And once again a greate article by james!
This posting is specifically a response to James Cowleys suggestion that using ByVal is quicker than using ByRef. This is only true when calling an out-of-process server (i.e. and ActiveX EXE). VB is designed to pass all parameters ByRef, which means that everything is passed as a 32-bit pointer. When passing ByVal VB copies the contents of the parameter into temporary space and then passes a 32-bit pointer to the temporary space. This means that, counter-intuitively, it is slower passing a long ByVal than it is ByRef.
When calling an out-of-process server OLE must marshal a copy of your parameter into the address space of the routine you are calling and then, if it is ByRef, copy it back afterwards. This is probably the only occasion that passing ByRef is slower.
Generally ByVal should be reserved for occasions when the routine is going to change the contents of the variable and the calling routine will be affected by the change. At the very least use ByRef for all strings and variants.
This thread is for discussions of Performance Issues.