Ideas in Wiring

Performance Hint

Since it's the first day of NIWeek, here's a performance tip for everyone

The traditional LabVIEW demo is to place a random number generator feeding a chart indicator inside a while-loop and running it. The application merrily generates nice wavy lines on the graph at high speed. Clone the loops so that there are two in parallel and they update simultaneously. It shows how quickly you can make some sort of interactive application with LabVIEW. Unfortunately, we are showing a bit of bad programming style in this demo. Luckily, there's an easy way to turn that example from a "huge consumer of CPU time" to an "appropriate programming model". Convert the while-loop into a timed-loop and set the loop speed to 60Hz. There's no reason to update your UI faster than the refresh rate of your monitor. It will save a lot of CPU bandwidth for other things.

This is a trick you can use at home. Look through your code and see if you have indicator terminals inside loops. Does that indicator really need to be inside that loop? Do you really need to update the indicator more than once? Updating an indicator takes time, especially when the front panel is visible (or even just in memory). If it doesn't need to be updated frequently, pull that indicator terminal out of the loop.

If the indicator really does need to be updated in that loop, are you waiting at all in the loop, either via the wait primitive or via the timed loop? If not, you should probably add one. Otherwise, you are going to eat a lot of CPU time doing needless work.

A few years ago, I took a look at a customer's application because it was running differently on a laptop than it did on our embedded controllers. The application had a main loop that was acquiring data and it wasn't running quickly enough. After peeking at it for 30 seconds in the LabVIEW profiler, I saw that it was spending 98 percent of its time in a subVI that wasn't even called in the loop. Huh? It turns out that the application was spawning a hidden dialog box that had no wait in it. As you may remember from my 55ms article, LabVIEW tries to balance the needs of parallel operations. This hidden dialog was eating all of the CPU time and crushing the performance of the application. Simply adding a wait primitive to that one dialog increased the data acquisition loop speed by TEN TIMES.

Check your waits
Use the profiler

posted by Joel @ 5:00 AM