LabVIEW Performance, The Early Years

I started working at NI in 1988, when LabVIEW 1 was shipping. LabVIEW 1 was so cool. But once you got past the awesome (for the 1980's) graphics and graphical programming paradigm and started to use it for real work, you noticed that it was a tad slow.

We learned a lot doing LabVIEW 1. So much so that we decided to throw away the source code and start over with LabVIEW 2. While LabVIEW 1 was an interpreted language, LabVIEW 2 was built from the ground up to be compiled. And when it came out in 1990, LabVIEW 2.0 demonstrated much better performance. For some applications, it was an order of magnitude or more faster. (So fast, in fact, that we ran into problems talking to many GPIB instruments that couldn't keep up with commands we were sending.)

LabVIEW 3 released in late 1993, and was the first version of LabVIEW that unified our original Macintosh codebase with our PC and Sun versions. Soon after, I created the first presentation to customers about LabVIEW performance...

In May 1994, I was invited to Sweden to present "Tips & Techniques for Improving LabVIEW Performance". It discussed how to take advantage of the many performance optimizations available in LabVIEW, and also discussed patterns to avoid, such as local variables. (Don't worry, I'll cover these in subsequent postings.)

My presentation was based on some earlier technical notes, as well as an article by Monnie Anderson in the now defunct LabVIEW Technical Resource. (LabVIEW Memory Secrets, Volume 2, Number 1, Winter 1994)

Before I left for Stockholm, I practiced the presentation in front of the LabVIEW team. This turned out to be a great experience—I presented to the toughest audience first. It did yield one unexpected result: the LabVIEW development team did not agree on how LabVIEW worked!

More precisely, I had found a common situation where LabVIEW made an extra copy of data that unexpected and unnecessary. Within a few days, our compiler expert had a fix that later came out in LabVIEW 3.1.

Why am I telling you these stories? Even though the latest LabVIEW is many orders of magnitude faster than LabVIEW 1, and even though we can handle much more complicated applications than we could a couple of decades ago, we're not resting. We're still working on performance issues today.

For example, we've seen much growth in the use of multi-core processors in affordable PCs. While LabVIEW has been ahead of this curve and able to take advantages of multiple processors and cores since our 1998 release of LabVIEW 5.0, we're continuing to look at new ways to leverage all this computing power.

Another reason for these stories is to make it clear that performance issues are sometimes difficult to understand. And I'm hoping that my future blog posts will help clarify these for you.

Next up... The three kinds of data in LabVIEW.