Among the many techniques for optimizing program code size, most include removing unnecessary elements from the code. Visual Basic automatically removes certain elements when compiling an application. There are no restrictions on the length or number of identifier names, comments, and blank lines. When the application is run as an .EXE file, these elements will not affect the memory size occupied by the application. Other elements, such as variables, forms, and procedures, do take up some space in memory. It's better to streamline them to make them more efficient. The following introduces 6 methods that can be used to reduce the memory required by the application and reduce the code size. I hope it will be helpful to beginners.
1. Reduce the number of loading forms and controls and use labels instead of text boxes
Each loaded form, whether visible or not, occupies a certain amount of memory (the amount varies depending on the type and number of controls on the form, the size of the bitmap on the form, etc.). Only load the form when you need to display it, and unload the form when it is no longer needed (rather than hiding the form). Remember, any reference to a form's properties, methods, or controls, or to a form variable declared with New, will cause Visual Basic to load the form.
When using the Unload method to unload a form, only part of the space occupied by the form can be released. To free all space, use the Nothing keyword to invalidate the form's reference:
When designing an application, forms should use as few controls as possible. The actual limit depends on the type of control and the system, but in practice, a form with a large number of controls will run slowly. A related technique is to use arrays of controls whenever possible when designing, rather than placing a large number of controls of the same type on the form. A control array is a group of controls with a common name and type. Their course of events is also the same. At design time, adding controls using a control array consumes fewer resources than adding multiple controls of the same type directly to the form. Control arrays are also useful when you want several controls to share code. The label control Label takes up fewer Windows resources than the text box Textbox, so when possible, a label should be used instead of a text box. For example, when a hidden control on a form needs to hold text, using labels is more effective.
2. Use disk files or resources and organization modules
Data placed directly into the application at design time (such as literal strings and values in properties or code) will increase the memory occupied by the application at runtime. Loading data from disk files or resources at runtime reduces memory usage. This is especially valuable for large bitmaps and strings. Resource files are actually composed of a series of independent strings, bitmaps, or other items, each of which has a unique identifier. Resource files can be created using a text editor and resource compiler similar to those provided in Microsoft Visual C. Compiled resource files have a .res extension.
Visual Basic only loads modules when needed, that is, when code calls a procedure in the module, the module is loaded into memory. If a procedure in a particular module is never called, Visual Basic never loads the module. Therefore, try to put related procedures in the same module and let Visual Basic load the module only when needed.
3. Consider replacing the Variant data type
The Variant data type is extremely flexible to use, but takes up more memory than other data types. When you want to compress excess space in your application, you should consider replacing Variant variables with other data types, especially replacing Variant variable arrays.
Each Variant occupies 16 bytes, while Integer occupies 2 bytes and Double occupies 8 bytes. A variable-length string variable takes up 4 bytes plus 1 byte for each character in the string. However, each Variant containing a string takes up 16 bytes plus 1 byte for each character in the string. bytes. Because they are so large, Variant variables are particularly annoying when used as local variables or arguments to procedures because they consume stack space too quickly. But in some cases, using other data types instead of Variant reduces flexibility, and more code has to be added to make up for the lost flexibility. The result is no real reduction in size.
4. Use dynamic arrays and reclaim memory when deleting
Use dynamic arrays instead of fixed arrays. When the data of the dynamic array is no longer needed, use Erase or ReDimPReserve to discard the unnecessary data and reclaim the memory used by the array. For example, use the following code to reclaim the space used by a dynamic array:
Here, Erase completely deletes the array, while ReDimPreserve only shortens the array without losing its contents:
Deleting a fixed-size array does not reclaim the space occupied by the array—it simply clears the value from each element of the array. If the elements are strings, or Variants containing strings or arrays, then deleting the array reclaims the memory occupied by those strings or Variants, not the memory occupied by the array itself.
5. Reclaim space used by string or object variables
When the process ends, the space used by (non-static) local string and array variables can be automatically reclaimed. However, global and module-level string and array variables survive until the end of the entire program. If you want your application to be as small as possible, you must reclaim the space used by these variables as much as possible. Assigning a zero-length string to a string variable reclaims its space:
Likewise, setting an object variable to Nothing reclaims some (but not all) of the space used by the object. For example, to delete a Form object variable:
Even if you are not using explicit form variables, you should be careful to unload forms that are no longer used, rather than simply hiding them.
6. Eliminate dead code and useless variables
As you develop and modify your application, you may be left with dead code—an entire process in your code that isn't called anywhere. There may also be some unused variables declared. Although Visual Basic can indeed delete useless constants when creating .exe files, it cannot delete useless variables and dead code. Be careful to review your code to find and remove useless variables and dead code. For example, the Debug.Print statement is ignored when running .exe, but it often appears in .exe files.
When creating an .exe file, Debug.Print statements containing strings and variables as parameters are not compiled. But for the Debug.Print statement that contains a function as a parameter, it itself is ignored by the compiler, and the function is compiled. So while the application is running, the function is called but the return value is ignored. Because in the .exe file, when the function appears as a parameter of Debug.Print, it will take up space and CPU cycle time, so it is best to delete these statements before generating the exe file.
Use the Find command in the Edit menu to search for references to a specific variable. Or when each module contains an OptionExplicit statement, you can quickly discover whether the variable is used by deleting or commenting the declaration of the variable and running the application. If this variable is used, Visual Basic will error. If no error occurs, the variable is not used. ->