| 1. Allocate A Unique DLL Base Address [0098] |
| To minimise memory usage and achieve optimal loading of ActiveX components, a unique base address must be determined for each ActiveX DLL/OCX. |
| |
| 2. Always Use Typed Optional Arguments [0115] |
| Optional variant arguments add additional overhead to execution which can degrade operational performance and also prevents strict type checking. Declaration of optional arguments 'As Variant' must be avoided whenever possible. |
| |
| 3. Avoid "GoSub" In Native Code Components [0147] |
| In components compiled to native code, "GoSub" statements are 5-6 times slower than calls to regular Subs or Functions; conversely, in P-code components they are considerably faster. |
| |
| 4. Consider Splitting "If" Statement Expressions [0259] |
| Consider splitting a single 'If' statement containing an 'And' expression into multiple nested 'If' statements. For example, 'If x=1 And y=1 Then' will cause both x and y to be evaluated. Splitting the expression into separate nested 'If' statements may reduce the time spent evaluating the expression on occasions when the expression does not evaluate to True. |
| |
| 5. Avoid Accessing "Count" Properties In "For...Next" Statements [0194] |
| When iterating an array variable using a For...Next loop, avoid accessing object Count properties directly in the 'For' statement. Instead assign the value to a temporary variable prior to commencement of the loop. |
| |
| 6. Avoid Late Bound Variables [0174] |
| Late binding to variables adds an additional overhead to execution which can degrade operational performance. Unless late binding is deliberately sought, declaration of variables of type "Object", "Form" or "Control" should be avoided whenever possible. |
| |
| 7. Avoid Nested Loops [0193] |
| Nested loop statements can occasionally lead to unexpected performance bottle-necks when the number of iterations is not confined to known limits. |
| |
| 8. Avoid Null String Comparisons [0126] |
| All string operations are expensive in processor time. When checking for an empty string (""), use the 'Len()' function instead to improve performance. E.g. 'If Len(sMyString) = 0 Then' instead of 'If sMyString = "" Then'. Avoid comparisons against vbNullString also. |
| |
| 9. Avoid Unnecessary Use Of "DoEvents" [0148] |
Don't fill your code with unnecessary "DoEvents" statements, especially within time-critical loops. If you use DoEvents just to trap mouse and keyboard activity, you can call it only if there are pending items in the event queue; you can check this condition with the GetInputState API function:
Declare Function GetInputState Lib "user32" Alias "GetInputState" () As Long
' ...
If GetInputState() <> 0 Then
DoEvents
EndIf
If you can't avoid that, at least you can reduce the overhead by invoking DoEvents only every N iterations of the loop, using a statement like this:
If (loopNdx Mod 10) = 0 Then
DoEvents
EndIf
|
| 10. Avoid Use Of "+" Operator For String Concatenation [0109] |
| The "+" operator must not be used for string concatenation. Always using "&" for string concatenation which is faster than "+" and also avoids any confusion when concatenating variants. |
| |
| 11. Avoid Variable Data Type "As Variant" [0088] |
| Variant variables add additional overhead to execution which can degrade operational performance and also prevents strict type checking. Declaration of variables 'As Variant' must be avoided whenever possible. |
| |
| 12. Compile For "Fast Code" [0127] |
| To improve performance, the compile optimization should be set to compile for 'Fast Code'. This option generally produces faster code albeit at the expense of larger memory footprints for components. |
| |
| 13. Compile To "Native Code" [0020] |
| Generally, to aid faster performance, all components and applications should be compiled to native code. (See "Compiled vs. Interpreted Applications" in the Visual Basic Documentation.) |
| |
| 14. Consider Compile For "Small Code" [0021] |
| To improve performance, consider setting the compile optimization to compile for Small Code. This option generally produces smaller memory footprints for components thereby avoiding unnecessary virtual memory access to disk. In operational circumstances where physical memory is in high demand, this may offer improved performance over Compile For 'Fast Code' which produces faster code at the expense of increased memory footprint. |
| |
| 15. Set ClipControls To False [0158] |
| If you are not using graphics methods (Line, PSet, Circle, and Print), you should set ClipControls to False for forms and for any frame and picture box controls. When ClipControls is set to False, Visual Basic doesn’t overpaint controls with the background before repainting the controls themselves. On forms that contain a lot of controls, the resulting speed improvements can be significant. |
| |
| 16. Use Image Controls Instead Of Picture Box Controls [0162] |
| Use of image controls instead of picture box controls improves the speed and minimises the size of your application if the functionality required is simply displaying pictures and reacting to click events and mouse actions on them. |
| |
| 17. Use Intrinsic String Constants Instead Of "Chr$()" Expressions [0190] |
| To improve performance, use of Chr$() expressions should be avoided whenever an intrinsic Visual Basic constant exists which may be used instead. For example, use of the expression "Chr$(9)" can be replaced with the Visual Basic constant "vbTab". |
| |
| 18. Use Module-Level Variables Instead Of "Static" Local Variables [0114] |
| While static variables are useful for storing values between multiple executions of a procedure, they are slower than local variables. By storing the same value in a module-level variable your procedure will execute faster. Note, however, that you will need to make sure that only one procedure is allowed to change the module-level variable. The tradeoff here is that code will be less readable and harder to maintain. |
| |
| 19. Use String "Hex$()" Function Instead Of Variant "Hex()" Function [0195] |
| Avoid use of the Variant "Hex()" function and use the String "Hex$()" function in preference to achieve improved performance. |
| |
| 20. Use String "Space$()" Function Instead Of Variant "Space()" Function [0196] |
| Avoid use of the Variant "Space()" function and use the String "Space$()" function in preference to achieve improved performance. |
| |
| 21. Use String Character Functions Instead Of Variant Character Functions [0189] |
| Avoid use of the Variant "Chr()" function and use the String function "Chr$()" in preference to achieve improved performance. A number of instrinsic constants exist which, if used instead of the equivalent Chr$() function, will also improve performance. |
| |
| 22. Use String Directory Functions Instead Of Variant Directory Functions [0199] |
| Avoid use of the Variant "CurDir()" and "Dir()" functions and use the String functions "CurDir$()" and "Dir$()" in preference to achieve improved performance. |
| |
| 23. Use String Extract Functions Instead Of Variant Extract Functions [0140] |
| Avoid use of the Variant "Left()", "Right()" and "Mid()" functions and use the String functions "Left$()", "Right$()", "Mid$()" in preference to achieve improved performance. |
| |
| 24. Use String Trim Functions Instead Of Variant Trim Functions [0139] |
| Avoid use of the Variant "LTrim()", "RTrim()" and "Trim()" functions and use the String functions "LTrim$()", "RTrim$()", "Trim$()" in preference to achieve improved performance. |
Recommended Book ...
