How to Optimize Memory Management in VB 3.0 for Windows

• Microsoft Visual Basic Standard and Professional Editions for Windows, version 3.0

SUMMARY

This article outlines how various memory areas in Visual Basic are managed. It covers the following areas:

• General Memory Management:
  
  
  • Windows Limits
  
  
  
  • Application Limits
  
  
  
  • Form Limits
  
  
  
  • Data Limits
  
  
  
  • Global Name Table
  
  
  
  • Global Symbol Table
  
  
  
  • Global Data Segment
  
  
  
  • Module Name Table
  
  
  
  • Module Symbol Table
  
  
  
  • Module Data Segment
  
  
  
  • Module Code Segment
  
  
  
  • System Resources
  
  
  
  • Stack Space
  
  
  
  • When Code and Resources are Loaded and Unloaded
  
  
  



• "Out of Memory" and Related Error Messages:
  
  
  • Common Ways to Avoid "Out of Memory"
  
  
  
  • Common Ways to Diagnose "Out of Memory"
  
  
  
  • Verifying a Memory Leak
  
  
  



• Optimization Recommendations
  
  
  • System Resource Overview
  
  
  
  • Visual Basic Controls: USER Resource Byte Use
  
  
  
  • Menu USER Resources
  
  
  
  • System Resource Optimizations
  
  
  
  • Size Optimizations
  
  
  
  • Speed Optimizations
  
  
  

GENERAL MEMORY MANAGEMENT

Windows Limits

Application Limits

• There can be a maximum of 256 distinct objects in a project.



• There can be a maximum of approximately 230 forms in a project, with up to 80 loaded at one time.



• The total count of all procedures, form and code modules, and DLL declarations must be less than 5,200, not counting event procedures that are empty of code.

Form Limits

• There can be a maximum of 470 controls on a single form, depending on control type.



• There can be a maximum of 254 different control names per form. A control array counts as one name.



• The data in all form properties and all control properties on a given form is stored in a single data segment limited to 64K, except for the List property of combo and list-box controls and the Text property of multiline text-box controls.

Data Limits

Global Name Table

• The actual text of the Form or Code module name.



• The actual text of each event procedure name appears in the Global symbol table only once. For example, two different forms each have a Form_Load event procedure, but only one entry for the event procedure is made in the Global symbol table.



• The actual text of each non-event Sub or Function procedure name in a form module (.FRM file). Even though these Sub or Function procedures are private to the form, within the application, their names are listed globally but with a flag set to indicate that they are private to that form.



• The actual text of each non-event Sub or Function procedure name in a code module (.BAS file). As with Sub or Function procedure names in a form module, the code module Sub and Function procedure names are listed globally but with a flag set to indicate that they are global to the application (unless the Private key word is used, in which case the flag is set to indicate that they are private to that code module).



• The actual text for the name of each Global constant.



• The actual text for the name of each Global variable.



• The actual text for the name of each user-defined type definition.



• The actual text for the name of each Global DLL Sub or Function procedure declaration.



• Four bytes of overhead for each of the above listed Global names in the Global name table as well as approximately 100 bytes of overhead for the hash table for these Global names.

Global Symbol Table

• Type definitions: 4 bytes for the type plus 4 bytes for each element.



• Type variables: 12 bytes.



• Fixed-string variables: 12 bytes.



• Object variables: 12 bytes (approximately).



• Everything else: 10 bytes (approximately).



• Approximately 100 bytes of overhead for the hash table within the Global symbol table.

Global Data Segment

Module Name Table

• The actual text for the name of each module-level and local variable name.



• The actual text for the name of each module-level DLL Sub or Function procedure declaration.



• The actual text used for line numbers and line labels.



• As with the Global name table, an additional four-byte overhead for each of the above listed module-level names in the Module name table as well as about 100 bytes overhead for the hash table for these module-level names.

Module Symbol Table

Module Data Segment

• Local variables declared with the Static keyword.



• Local variables declared within a Static Sub or Function procedure.



• Module-level, fixed-length string variables.



• Module-level variables other than arrays and variable-length strings.



• Module-level constants.



• Tracking data for arrays and variable-length strings (2-byte pointer each).



• Tracking data for controls referenced in code for a form (2-byte pointer each).



• Tracking data for nonstatic local variables (2-byte pointer each).

Module Code Segment

System Resources

• Use the Visual Basic Load and Unload statements to load forms only when needed at run time.



• Use so called lightweight controls (labels, images, lines, and shapes in Visual Basic version 3.0) when possible. These controls are similar to other controls in that they do use system resources when they are being drawn or updated in the screen. But unlike other controls, the lightweight controls release resources back to the system when finished.



• Replace controls such as command buttons that react to mouse events with an image control that has a picture of a control in it. This provides your application with similar functionality but uses less memory (system resources).



• Try to replace several related controls with a single, larger control. For example, if several text boxes were placed on a form to represent the cells of a spreadsheet, you could replace these controls with a single picture control containing an image of the cells: lines drawn vertically and horizontally. Hit testing could be performed at run time from within the MouseDown event of the picture control. In other words, you could use the x and y coordinates passed to the MouseDown event to determine which "cell" was clicked (hit). The cell image on the picture control could be temporarily replaced by a real text box, positioned by using the Move method to allow for user input. In this manner, only two controls would be required to simulate input on a spreadsheet: a picture control and a text box.

Stack Space

   Sub Command1_Click ()
      Dim frameCount as Integer
      frameCount = 0
   Overflow_Stack:
      Me.Cls
      frameCount = frameCount + 1
      Print frameCount * 4
      GoSub Overflow_Stack
   End Sub 

When Code and Resources Are Loaded or Unloaded

   Unload Form2
   Set Form2 = Nothing 

"OUT OF MEMORY" AND RELATED ERROR MESSAGES

Common Ways to Avoid "Out of Memory"

• Read Appendix D (Specifications and Limits) of the "Programmers Guide." The discussion of the Global symbol table in the manual is enhanced by details presented below.



• Read Chapter 11, "Optimizing Your Applications for Size and Speed," in the "Programmer's Guide." This offers a good starting place in its discussion of optimizing your applications memory requirements.



• Keep the number of forms loaded at any given time to as few as possible. While the specifications indicate that 80 forms can be loaded into memory, in practice you will want to avoid pushing this upper limit.



• If possible, take advantage of non-graphical ("lightweight") controls (shape, line, image, and label). These controls use less system resources as well as memory.



• Use control arrays if possible rather than a large number of static controls of the same type.



• Minimize the number of controls on a form. The upper limit of controls on a form is 470; however, they can use only 254 control names (making control arrays necessary). In practice, a form this heavily laden with controls would be slow in performance. Minimize the number and type of custom controls on a given form.



• Save your forms and modules as text. See the "Module Code Segment" discussion above for details.



• Ensure that the declaration for any API or other DLL calls you make are correct. Ensure that memory allocated by routines inside a DLL is actually deallocated when the process using it is finished.



• Explicitly turn off timer controls when your application exits. If you do not, it is possible the parent form will not be unloaded, and the timer will continue firing.



• Explicitly unload forms; especially when the application terminates. The End statement does not trigger the Unload event of a form. The only way to ensure that a form is actually unloaded is to issue the Unload statement. The Forms Collection is useful for being certain that all forms, loaded or not, are unloaded.

Common Ways to Diagnose "Out of Memory"

• Remove any and all unnecessary device drivers from the CONFIG.SYS file. Is there any particular problem that seems to induce the error?



• Remove any TSR (terminate and stay resident) programs from the AUTOEXEC.BAT file. Again, is there any particular TSR that induces the error?



• Use Program Manager as the Windows desktop.



• Do not run anything else in Windows that is not necessary. Check this by bringing up the task list (CTRL-ESC). Are Visual Basic and the Program Manager the only tasks running?



• Change the Windows Video driver to standard VGA. It may be necessary to check if your display's vendor has released an update to the display driver. There may an incompatibility with your video driver and Visual Basic causing video memory to be incorrectly allocated or referenced.



• Change any API or DLL calls you are making into comments by adding a single quotation mark as the first character on the line. This may not be conclusive, as the error can be generated as a result of the values returned by the calls, and not the calls themselves. In that case, hard code the return values, or provide some mechanism to simulate their action so you can test the code that responds to them.



• Remove any custom controls you are using from the form.



• Check to see whether you are legitimately low on RAM or the hard disk is almost full. 386 enhanced mode gives you more logical RAM than you have physical RAM, but only if you have the hard disk space free to allow this.

Verifying a Memory Leak

OPTIMIZATION RECOMMENDATIONS

System Resource Overview

Visual Basic Controls: USER Resource Byte Use

   Form .......... 206 | FileListBox .... 160 | PictureClip ..... 72
   MDIForm ....... 420 | Shape ............ 0 | SpinButton ...... 72
   PictureBox ..... 90 | Line ............. 0 | SSCheck ......... 72
   Label ........... 0 | Image ............ 0 | SSFrame ......... 80
   TextBox ........ 76 | Data ............ 72 | SSOption ........ 72
   Frame .......... 74 | Grid ............ 72 | SSCommand ....... 76
   CommandButton .. 66 | OLE ............ 164 | SSPanel ......... 80
   CheckBox ....... 76 | AniPushButton .. 170 | SSRibbon ........ 80
   OptionButton ... 76 | CommonDialog ... 166 |
   ComboBox ...... 136 | CrystalReport .. 166 |
   ListBox ....... 160 | Gauge ........... 80 |
   HScrollBar ..... 80 | Graph ........... 80 |
   VScrollBar ..... 80 | MhState ......... 72 |
   Timer .......... 72 | MSComm .......... 72 |
   DriveListBox .. 160 | MaskEdBox ....... 76 |
   DirListBox .... 160 | Outline ......... 82 

Menu USER Resources

System Resource Optimizations

1. Break large forms (forms with many controls) into several smaller forms. Each of the smaller forms can be loaded and unloaded as necessary. Since only one of these forms at any given time is loaded, system resources will be used less. However, the added overhead of loading and unloading forms will most likely result in slower application performance, so there is a tradeoff.



2. Implement control simulation. For example, a form could implement a toolbar by using 20 command buttons, consuming 1320 bytes of system resources. The toolbar can be implemented more efficiently with two image controls and one PictureClip control. The first image control contains one bitmap that looks like the entire toolbar. The PictureClip control contains one bitmap that contains the button down appearance of all buttons on the toolbar. When the user clicks on the toolbar (image control) the corresponding down picture is retrieved from the PictureClip control, placed in the second image control, and placed over the toolbar in the correct position. The second image control is hidden on the mouse up giving the appearance of button depression. This solution consumes 72 bytes of USER resources for the one PictureClip control. The image controls are graphical controls which consume zero USER resources.
   
   A second area of control simulation is text boxes. Applications that are data entry intensive contain many text-box controls. For example, if a form contained 64 text-box controls, they would consume 4864 bytes of USER resources. A simulation solution would use 1 text-box control and 64 label controls. When the user clicks on a label to edit it, the text box is resized and moved to the clicked label. This requires more coding to handle the one text box, tabbing, and access keys. This solution consumes 76 bytes of USER resources for the one text-box control. The label controls are graphical controls which consume zero USER resources.



3. Consider redesigning the user interface. For example, many option buttons can be replaced by one combo box and many check boxes can be replaced with one multiselect list box. Some controls may be an overkill for the desired functionality. For example, using a picture box, when all that is needed is an image control.

Size Optimizations

1. Put strings into external DLL's:
   
   
   • Doing this gives a much greater ease of converting text into other languages.
   
   
   
   • It also helps reduce the sizes of the code segments in the Visual Basic app.
   
   
   
   • It slightly slows down the initial loading of forms.
   
   
   
   • Strings can be stored in a String Table Resource inside the DLL.
   
   
   



2. Reduce unnecessary code replication.
   
   Having the same code in multiple places will generally increase the size of the app. It also increases maintenance costs. In some cases it may be necessary to have the same code in multiple places, and such instances should be commented to indicate the need.



3. Use Constants rather than string literals:
   
   
   • When used as a parameter, a string literal takes up a minimum of 6 bytes, whereas a string *constant* takes 4 bytes.
   
   
   
   • When assigned to a string variable, a string literal takes up a minimum of 8 bytes versus the 4 bytes for a string constant.
   
   
   
   • Converting a parameter from a string literal to a string constant saves 4 bytes in the code segment, for every instance beyond the first.
   
   
   
   • Converting an assigned string literal to a string constant saves 2 bytes in the first instance, and 6 bytes for every instance beyond the first.
   
   
   



4. For strings that are used throughout the program and are Read Only, use Global string variables. Be cautious about this approach since the Global Symbol Table has a limit of 64k for storing variable names. It[ASCII 146]s best to use this method for strings that are repeated a lot.
   
   Define the strings as Global, set them up in an Initialization module, and then use them in other modules instead of constantly recreating things like Chr$(9):

   
        Global TABCHR as String * 1
        Global CR as String * 1
        Global CRLF as String * 2
   
        Sub Init()
          TABCHR = Chr$(9)
        CR = Chr$(13)
        CRLF = CR + Chr$(10)
        End Sub
    

   By constantly using Chr$(9), the code is larger, and it is slower since it must re-create the character every time that code is executed.



5. Put IF/THEN constructs on one line if possible.
   
   The ENDIF generally takes up 6 bytes, thus changing:

   
         If X=2 Then
            debug.print "HI"
         EndIf
    

   to:

   
         If X=2 Then debug.print "HI"
    

   This winds up saving 6 bytes to do the exact same function.



6. Check to see whether the Visual Basic function you're using is really needed.
   
   Sometimes this means checking the function to see if the returned value really needs the additional work you're doing, such as:

   
         Trim$(Format$(123))
    

   In which case, the Trim$() is totally unnecessary. Other times, this means looking at what is being created, and seeing if it could be done at design time, such as " 0" instead of using Str$(0).



7. Put functions that are only used one time, or are used seldom in their own modules. Visual Basic loads modules on demand and Windows will discard them if they don[ASCII 146]t get used after a while:
   
   
   • Modules such as a Print module and an Initialization module can be loaded one time by the code and then discarded when no longer needed.
     
     -or-
   
   
   
   • If a special startup form is going to be used, the initialization code could be placed in that form, so the code will be unloaded with the form.
   
   
   



8. Use Bit fields rather than strings.
   
   Not only does an integer take up less space in memory than a 16 character string, but it is much faster to do comparisons! i.e., it would be much faster, and more efficient, to check for the existence of multiple flags via:

   
         If (Flags And TestVal) Then ...
    

   than an associated routine which has to scan multiple characters in a string to see if any of them are a "0" or "1".



9. Remove unnecessary value checks.
   
   For example:

   
         If  bFlagToBeTested = True Then ...
    

   can be written as:

   
         If  bFlagToBeTested Then ...
    

   Removing the "= True" saves 6 bytes from the module or form and is faster to execute. (Note: It also means that any non-zero value can be evaluated as "True".)



10. Do calculations manually at design time rather than asking the compiler to do them at run time.
    
    
    • If a data structure is only used for its size, store the size information in a Global constant or variable rather than keeping the entire structure around just to use the Len function. For example, use Const COMPANYREC_LEN = 505, rather than using Len(COVar). This avoids keeping a form-level variable around just so its length can be calculated!
      
      Or if the record sizes are being changed a great deal, then at least move the calculation to an initialization module, and do it only one time! In this case, a 505-byte data structure was loaded into memory every time a form that used Company data was loaded.
    
    
    
    • Even numeric calculations take up both execution time and space in the EXE: For example, use MinFree& = 102400& instead of MinFree& = 1024& * 100&.
    
    
    



11. Move graphics from the application to a DLL.

Speed Optimizations

1. Never reference an object property more than once.
   

   
      Poor:
   
         if Form1.Caption = "ABCD" then
         elseif Form1.Caption = "DEFG" then
         elseif Form1.Caption = "XYZ" then
         endif
   
      Better:
   
         Temp$ = Form1.Caption
         if Temp$ = "ABCD" then
         elseif Temp$ = "DEFG" then
         elseif Temp$ = "XYZ" then
         endif
   
      Even Better:
   
         Select Case Form1.Caption
            Case "ABCD"
            Case "DEFG"
            Case "XYZ
         End Select
   
      Best:
   
         CONST CASE1 = "ABCD"
         CONST CASE2 = "DEFG"
         CONST CASE3 = "XYZ"
         ...
         Select Case Form1.Caption
            Case CASE1
               Case CASE2
            Case CASE3
         End Select
     

   The last version is the best, because it uses constants for the strings (easier to maintain, less memory used, faster execution) and because it only references the variable (Form1.Caption) one time, rather than multiple times as the IF/ELSEIF constructs do. Using Select/Case statements will result in faster execution, however, it will be at the cost of slightly larger code.



2. Avoid calling routines outside of the current form or module to reduce swapping problems on low-memory machines
   
   Calling routines in a central location is okay but this can lead to inefficiency. A routine in one module which calls a routine in a second module, which calls a third routine in yet another module, etc. means that all of those modules have to be loaded. Doing this can cause excessive hits on the Windows SwapFile. To alleviate this, make sure that as many of the subordinate routines that your routine needs are located in the same module.



3. It is more efficient in Visual Basic to have local references to the current form's controls than it is to reference the proper form and then the control. Put subroutines or code that use controls in the form instead of a module whenever possible. For example:
   

   
      Module1
   
         Sub DoWork
         Form1.Text1.Text = "ABC"
         End Sub
   
      -versus-
   
      Form1
   
         Sub DoWork
         Text1 = ABC
         End Sub
      




4. Make smaller modules:
   
   Normal Windows programmers look for segment sizes in the range of 4-8k. Since there is no easy way to determine how much space a particular module in Visual Basic is taking up, sometimes we can only guess. The best approach is to put subroutines that work together into the same module. Then try to make that module as small as possible.



5. Use specific object types:
   
   
   • When calling a subroutine or function and passing an object, specify the exact object type being referenced. For example:
     

     
              Sub SubRtn1 (TxtBox as TextBox)
     
              -instead of-
     
              Sub SubRtn1 (TxtBox As Control)
          

   
   
   
   • If a subroutine is modifying a specific object, then use the exact control or form rather than referring to it via a parameter. This will cut down on the number of parameters and increase the speed of execution.
   
   
   



6. Use Windows API functions to draw artwork or backgrounds on the form rather than using Picture boxes or Image controls. Using the Windows API will help make some of the forms draw quicker.

REFERENCES

• Visual Basic version 3.0 for Windows "Programmer's Guide," Appendix D, "Specifications and Limitations," pages 641-646.



• Visual Basic version 3.0 for Windows "Programmer's Guide," Chapter 11, "Optimizing your Application for Size and Speed," pages 255-263.



• Microsoft Windows Software Development Kit "Programmer's Reference," Volume 2, "Functions."

Additional query words: 3.00 MemLeak

Keywords          : kbcode PrgOptMemMgt 
Version           : 3.00
Platform          : WINDOWS 
Issue type        : 

Last Reviewed: May 20, 1999