Improving Performance of LabWindows™/CVI Applications

Issue Details

Solution

• When developing applications, it is typical practice to create debuggable components. In LabWindows/CVI, when you set the Build » Configuration option to "Debug", LabWindows/CVI includes debug code in the component and generates a .cdb file that contains a symbol table and source position information necessary for debugging. The amount of debugging information included in the component and the .cdb file depends on the value of the Debugging level option in the Build Options dialog box (Options » Build Options). Once you have finished debugging your application, you should build and distribute your component in the Release mode. A component set for Release is smaller and will run faster. 

• If your events are not getting processed in a timely fashion, there are two possible causes:

1. ProcessSystemEvents() is sleeping too long between calling events. The LabWindows/CVI sleep policy is either programmatically set by calling SetSleepPolicy() or through the Options » Environment menu. The setting that is optimal for you depends on the operating system you are using and the other applications you are running. Generally for Windows, its recommended to use the Sleep more mode. However, if you think you might need to make an adjustment, try the different settings and observe the resulting behavior. 
2. A callback in your application is taking too long to process. Callbacks are processed synchronously in LabWindows/CVI. Your callback development goal is to make the callbacks as fast as possible as they should execute their code, return and allow other callbacks to execute. If a callback is going to take a long time to process, you can insert ProcessSystemEvents() throughout your lengthy callback (especially in loops). However, even though this method is easier, its less efficient. For better performance and responsiveness (though more difficult), implement the lengthy code in a separate function. Then have the callback function create a separate thread that runs the lengthy function. Refer to the related links section below for further information.

• Try increasing the process priority and/or thread priority of important threads in your application. You can set the priority of a thread that you create in LabWindows/CVI by using the CmtScheduleThreadPoolFunctionAdv() or CmtSetThreadPoolAttribute() functions. Be warned that the Realtime priority can make your entire system unresponsive and/or crash. Use it only for short bursts, such as when a task is vital, and then lower the priority back to normal (or consider using High priority instead). Refer to the related links section below for further information. 

• The LabWindows/CVI compiler does not create optimized code. You can create optimized code by compiling LabWindows/CVI source code using an external optimizing compiler. To compile in an external compiler, you must set up a compiler configuration, which contains information about the external compiler and compiler options to use. Refer to the LabWindows/CVI Help for further information. 

• If several regions of the program will run independently of each other but must synchronize at some point , you can use OpenMP (Open Multi-Processing) API . OpenMP is appropriate to use in a program that consists of tight loops where the loop iterations are independent of each other so that subsets of iterations can run in parallel on multiple processing cores. For more information of OpenMP, please look at the Related Links.

• There are a couple non-LabWindows/CVI dependent tactics to test out which are:
  • Check and see if other processes on your system are hogging the CPU. If so, quit them and see if this speeds up your LabWindows/CVI application. 
  • Test out this application on another computer, perhaps with different hard-wired configurations such as a faster process, different video card, etc.