Performance Issues

Increasing Speed

Have a performance tip that you would like mentioned? Email us with it.

There are a large number of factors that affect the speed of your program. Below is a list of some of them.

  • Pass variables ByVal instead of ByRef (the default).
    This way, Visual Basic does not have to send the address of the variable, and retreive it after the procedure has been called. For more information on this, click here.

  • Use the magic $.
    When using string functions that have an alternative function with a $ after it, use that instead. Click here for why!

  • Don't calculate the same thing over and over again.
    For example, if you constantly want to know the length of a string that does not change, save the length to a variable, instead of constantly calling the Len function.

  • Don't ask for the same thing over and over again.
    When constantly requesting a property (ie the Text property of a RichTextBox), which you know will not change, save the value to a local variable, and use that instead. It is much quicker! For example
    sBuffer = RichTextBox1.Text
    For i = 0 To Len(sBuffer)
        sTemp = Mid$(sBuffer, i, 1)
        Msgbox sTemp
    Next

  • Use Select Case instead of multiple If...ElseIf statements.
    This is much quicker.

  • Tell the control to stop redrawing.
    If you a performing a lot of operations on a control at once (for example, formatting different parts of text in a Rich Text box), use the WM_SETREDRAW constant with the SendMessage Win API call, or the LockWindowUpdate API call to stop the control constantly redrawing. This makes your program look tidier (so that the control is not constantly flickering as your code runs), and improves performance (because the control does not have to constantly redraw). Here is how to use the two Win API calls:
    For using SendMessage:
    Private Declare Function SendMessage Lib "user32" Alias "SendMessageA" (ByVal hwnd As Long, ByVal wMsg As Long, ByVal wParam As Long, lParam As Any) As Long
    Private Const WM_SETREDRAW = &HB
    '// Use this for stopping redrawing:
    SendMessage TextBox1.hWnd, WM_SETREDRAW, False, 0&
    '// Use this to redraw again:
    SendMessage TextBox1.hWnd, WM_SETREDRAW, True, 0&
    TextBox1.Refresh

    For using LockWindowUpdate
    Private Declare Function LockWindowUpdate Lib "user32" Alias "LockWindowUpdate" (ByVal hwndLock As Long) As Long
    '// Use this for stopping redrawing:
    LockWindowUpdate TextBox1.hWnd
    '// Use this to redraw again:
    LockWindowUpdate 0

    LockWindowUpdate is easier and quicker, however, if the form itself is requested to do so, it will (ie if the form in minimized and then maximized again), and the request for no redrawing will be lost.

  • Use the With statement.
    If you have a loop where you reference a control or object over and over, use the With/End With statement block. It will stop VB from constantly looking up the address reference to the object each time it is encountered. VB will look up the reference only once at the beginning of the block saving redundant lookups. (Thanks to Jeffery Bogusz)

  • Use Labels instead of TextBoxes, unless the user needs to type into the TextBox. If you like the look of the TextBox you can reproduce it by setting a Labels border to Single. (Thanks to Sirius Lee)

  • Use control arrays for any related controls, especially with Label controls that just display text and do nothing else. This saves memory, and increase efficiency. This also works really well with Option Controls contained in a Frame. Thanks to Sirius Lee.
  • Set the AutoRedraw property to False.
    Unless you have pictures that are updated often, you can set the Autoredraw to False and as long as you placed controls correctly, no overlapping, set the Clip Controls option to False. (Thanks to Sirius Lee)
  • Use the Static variable type only where necessary
    Instead, use the variable at the module level (i.e. declare it as private in a form or module). This increases the speed of operation with this variable. The advantage of using of variable Static type on level of procedure is the readability of code, the disadvantage is the speed of operation with this variable. Therefore it is better to use variables declared in module (the value of this variable remains the same at all procedures in this module). (Thanks to Lada Simicek)
  • Only use public variables where necessary
    If your variable does not need to be accessed outside the form/module etc, declare it as private!(Thanks to Berton Christophe)
  • Reduce frequent calls to the same procedure and replace it by using code.
    When your program frequently calls the same procedure (cycle), the speed goes down. In this case, it is recommended to write code of called procedure directly in the cycle. The advantage of it is the faster speed, the disadvantage is worse readability of the code. (Thanks to Lada Simicek)
  • Use constants instead of variables wherever possible.
    If you want to use the values that will not be changed, use constants. (Thanks to Lada Simicek)
  • Use early-binding.
    Don't declare as object if at all possible. You can use polymorphism when using similar classes.

Have a performance tip that you would like mentioned? Email us with it.

You might also like...

Comments

About the author

James Crowley

James Crowley United Kingdom

James first started this website when learning Visual Basic back in 1999 whilst studying his GCSEs. The site grew steadily over the years while being run as a hobby - to a regular monthly audien...

Interested in writing for us? Find out more.

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“Theory is when you know something, but it doesn't work. Practice is when something works, but you don't know why. Programmers combine theory and practice: Nothing works and they don't know why.”