LabVIEW
Darren's Weekly Nugget 11/30/2009
- last edited on by
Content Cleaner
If you're having performance problems in your LabVIEW application, the VI Profiler is one of the easiest ways to pinpoint, at the subVI level, where bottlenecks occur. The easiest way to illustrate this tool's usefulness is with a real-world example. While testing the VI Analyzer Toolkit 2009 earlier this year, I noticed that it was taking an unusually long time to launch, both when I was using the interactive UI and the programmatic interface. So I figured I would use the VI Profiler to benchmark the execution of a very simple VI, that creates, then destroys, a VI Analyzer analysis task:
I launched the VI Profiler from Tools > Profile > Performance and Memory..., clicked "Start", ran my VI, then once it was done, clicked "Snapshot". Here's what I saw:
When sorting these results by the VI Time column, I saw that the VIAnUI Get Test Rankings.vi took way more time than anything else in the VI hierarchy. I found this rather strange, given the simplicity of that VI's diagram:
This VI hasn't changed in a long time, yet I hadn't noticed the VI Analyzer launch slowdown until recent versions of the toolkit. That's when I realized what the problem was. As you can see, I am closing the reference to each test VI once I've retrieved its ranking. Well, in LabVIEW 8.6, all the VI Analyzer Toolkit tests were added to a project library to support licensing of the toolkit. And when you open a reference to a VI in a library, the library must be loaded into memory as well. So in the code above, I am loading, then unloading the VI Analyzer Toolkit library on each iteration of the loop. The fix was to simply build up the VI references on the loop output border, then wire the array of references to a single Close Reference function on the outside of the loop. Once I did this and reran the benchmark VI, I got these results:
This subVI's performance increased 10x, and the overall execution time of the benchmark VI decreased from 7.5 seconds to 1.5 seconds. The fix was extremely simple, but it would have been very difficult to track down without the help of the VI Profiler.
Oh, and I didn't investigate this until after VI Analyzer 2009 released...so you'll have to wait until VI Analyzer 2010 to enjoy the faster launch time. 🙂
I wonder if there are any particular things to keep in mind while deciding when to use "Close Reference" with all references together after a loop and when to use "Close Reference" inside the loop.
When I started off in the world of references, I used to close them once I'm done with them (i.e. in the loop). Then one fine day I realized that I can index the references and close them in one go (i.e. outside the loop), improving the performance significantly. Then just the other day, I find out that it is more advisable to close them as soon as I'm done using them again. 
ummm... Pretty clueless... 
Is this a memory usage vs time taken trade-off?
Very cool.
And we can use it in the similar structure.
But I wonder if you will release a patch for VI Analyze2009
- last edited on by
Content Cleaner
Darren wrote:
The fix was to simply build up the VI references on the loop output border, then wire the array of references to a single Close Reference function on the outside of the loop.
I never knew that the Close Ref function can accept an array of references.
