Archived: Performance Considerations for LabVIEW on Windows 2000

NI does not actively maintain this document.

This content provides support for older products and technology, so you may notice outdated links or obsolete information about operating systems or other relevant products.


Windows 2000 kernel schedules threads and processes in a manner slightly different than previous versions of Windows. This new mechanism might unbalance LabVIEW 5.1 or earlier (and other software programs that use multithreading), unless you disable the application boosting feature of Windows 2000.



Windows NT has the concept of priority boosting, which gives the active application (the one highlighted in the taskbar) a higher priority so it receives a larger allocation of processor time. Because the active application received more processor time, it ran faster than other running applications.

Windows 2000 made two changes to this concept.  First, the priority boosting option was changed from a slider scale to an on-off option. This option is located in the Advanced tab of the System Properties Control Panel applet, as shown in Figures 1 & 2.

Figure 1: System Properties Control Panel

Figure 2: Performance Options

The Performance Options dialog box contains a radio button that allows you to select whether boosting occurs.  When you select Background services, boosting does not occur.  When you select Applications, boosting occurs.

The second change in Windows 2000 has a much more adverse effect on LabVIEW (and other software programs that incorporate multithreading). Microsoft changed the way that the boosting is performed. In Windows NT, boosting was performed on the application and boosted all threads of the application. In Windows 2000, it appears to give individual threads priority based on some unknown heuristic. Unfortunately, the new boosting algorithm tends to boost the thread that updates the user interface.  While this provides smoother updates to dialog boxes, it also generates some large performance problems.

Boosting Example #1

This following VI does not behave correctly when run in LabVIEW 5.1 on Windows 2000. 


If the performance option is set to Applications, the front panel indicator jumps to 130,000 almost immediately. It then takes about 20 seconds to count up to 200,000 because the front panel is constantly redrawing.
If the performance option is set to Background services, the front panel indicator displays 11, then a number around 130,000, and then 199,999 and the VI finishes executing. The entire execution takes approximately .1 seconds.
This VI runs 200 times slower when the performance option is set to Applications.

Boosting Example #2

Windows 2000 also changes the relative priorities between non-user interface threads. In the following example hierarchy, suppose you open the front panels of the LoopinStd VI and the LoopInOther1 VI, and run the Untitled VI.


If the performance option is set to Background services, both indicators count fairly consistently and stay close to each other. 

If the performance option is set to Applications, the output is very different. One VI comes to a complete halt while the other one runs for a short while. Then the other VI halts while the first one runs.


At this time, National Instruments recommends that you always set the performance option to Background services.

Was this information helpful?