LabVIEW Environment Responds Slowly to Updating Code

Updated Nov 2, 2023

Reported In

Software

  • LabVIEW

Issue Details

Loading a large VI in LabVIEW causes LabVIEW to respond sluggishly. When I move an item on the front panel or block diagram (with or without pressing Ctrl + dragging), it will hang for a second before moving or it will move very slowly. Sometimes when I open the block diagram, some wires do not show up until I manipulate the diagram. I don't see this sluggish behavior outside of LabVIEW. How can I improve performance?

Solution

This problem could be due to the high-resolution setting of your monitor and the use of a multitude of colors. Large VIs with many front panel updates can also cause this behavior. When you move the mouse and select objects on your front panel, LabVIEW has to redraw the front panel for it to update. LabVIEW uses double-buffering to make screen updates appear smoothly and quickly. This process involves drawing the window contents in an off-screen buffer window where the updates are made and then copying the new window contents to the front panel. Copying the window contents gets more memory intensive as the resolution and the color depth increase.

Troubleshooting has three main paths: 
  1. Computer Settings
  2. LabVIEW Settings
  3. Code Architecture
If you see this behavior with any VI, independent of its size or the number of subVIs it holds, start with Computer or LabVIEW settings. If this only occurs with large VIs, it is more likely rooted in a Code Architecture problem.
 

Computer Settings

To correct this problem, first, try changing your resolution and color settings. Try setting your computer to a resolution of 800 x 600 pixels, with 256 colors and a refresh rate of 60 Hz. Then increase your resolution and color display settings from there. Check with your OS manufacturer on how to adjust your screen resolution (e.g. Microsoft's Change screen resolution for Windows 10).


Another potential solution is to change the "hardware acceleration" setting for your PC. Check with your OS manufacturer on how to adjust this setting. 
  • For Windows 7, right-click on the Desktop >> Screen Resolution >> Advanced Settings >> Troubleshoot >> Change Settings. From here the Hardware acceleration setting can be adjusted. It is suggested that you experiment with the slider, reducing the level of acceleration until you experience a more desirable behavior. Your computer may need to be restarted for the new settings to take effect. 
 

LabVIEW Settings

The next suggestion is to try disabling the "smooth updates" setting for the front panel.

In LabVIEW 2010 and later:
  • Right-clicking a graph on the front panel and selecting Advanced >> Smooth Updates. Note: This method does only work for Graphs, not with Charts.
  • Decreasing the number of undos saved can free up some memory. The default is 99 undos, and LabVIEW uses memory to store these undos.
  • To change the level of undos, go to Tools >> Options. and select the Environment Category. Change the Maximum undo steps per VI to about 10 to limit memory usage but still maintain the undo functionality.
 

Code Architecture

  • Another solution to slow-editing is proper VI Memory Management. This includes breaking a large VI into subVIs, limiting the use of global and local variables, and making sure there are no overlapping controls on the front panel. You can find out the memory usage of your VI by clicking File >> VI Properties. Change the category to Memory Usage.
  • From the block diagram, you can create a subVI from existing code by selecting the code to become a subVI and then clicking on Edit >> Create SubVI. The code will be replaced with a subVI icon. You can edit the subVI by double-clicking on the icon. More information about creating a subVI from existing code can be found here: Create and Configure a LabVIEW SubVI.
  • If placing a specific subVI in the block diagram causes the sluggish behavior of the development environment, try checking the dependencies of the subVI to see if there might be unnecessary references/dependencies that are causing the behavior. Once you have identified these unnecessary dependencies remove them, save the subVI and check if there is a change in the behavior.
  • Opening the top-level VI to edit as a stand-alone VI can decrease editing lag. To do this, open LabVIEW, open the top-level VI stand-alone and not from the project, save the top-level VI and proceed to edit normally from the project. 
  • Silver Controls and Indicators on the Front Panel take up more memory than the Classic ones. To change this, go to File >> VI Properties >> Editor Options. In Editor Options, change the Control style to Silver. You can also change the controls and indicators individually by right-clicking and selecting Replace.
  • If large controls or indicators, such as multiple graphs, have default values, then try clearing the object and making the cleared or empty state the default. To make a value the default, right-click and go to Data Operations >> Make Current Value Default. To clear a graph, right-click the graph, and select Data Operations >> Clear Graph. Then make the cleared graph the default. This will free up some memory in the VI.
  • If a project was originally written in a previous version and has not been mass compiled up to the current version, it could be causing the slowdown. From the top-level VI, do a Save All by going to File >> Save All. Also, try running a mass compile on the project that is showing the slowdown of the development environment.

  • The block diagram size can have a large impact on the performance of a VI. It is recommended to keep the block diagram size reasonably small. The best practice is to make all of a single VI fit on a single screen, and have minimal scrolling needed to see everything in the code. Extremely large diagrams that require lots of scrolling, can hurt the performance of a VI. 

Additional Information

If these remedies are unsuccessful, you may consider upgrading your video card driver or the card itself. The latest versions of video card drivers can be found on the respective manufacturer's website. This often helps out when you want to run at a high resolution with multiple objects on the front panel and an older video card is being used.