LabVIEW Performance and Memory Management

[Elijah_K]

LabVIEW Performance and Memory Management

Goals:

• Understand the LabVIEW Execution System
• Learnto improve performance by:
  • Reducing data copies
  • Reducing overall memory usage
• UnderstandVI Execution Properties

[TroyK]

This document is GOLD for advanced users!

It includes so many of the advanced tips I've picked up during the hours I've spent scouring through the forums.

[WG-]

Question, or rather a confirmation, regarding sheet 11 on the presentation:

"If the VI has UI code in it then that code must run in the UI thread."

So do I understand it correctly that even if I use something as simple as a Property node to fetch the label text it still ends up on the UI thread? If yes does this change if you change the execution of the VI to subroutine?

Further why are "subroutine" priorities not recommended? I often use this "priority" for small pieces of code and code that have/need no error handling, because the code is trivial in what it must do. Example take the OpenG array reorder VI it has the priority "subroutine". But if it would have the priority "normal priority" it is much much slower. Where does this "huge" difference come from, because it only includes 2 inputs, the array and the indices with the new array order, a for loop and index array function? Because this in fact states to me that there is a 'big' difference between the priority "normal" and "subroutine".

[LuI]

Subroutine priority has its usage for small overseable quick 'tasks', but has its disadvantage as well. Most important is that cooperative multitasking in the execution system where the subroutine runs in is disabled. You can run in race conditions when interacting with other parts of your code.

Finally it is like a sharp sword - may be usefull for certain tasks, but also quite dangerous. So use with extra care!

[Ben]

LV must be running in the UI thread to handle the property nodes. If the VI they are in are not configured to run in the UI thread, it will incur a thread swap to do the node work. If you have multiple prop node then there will be multiple thread swaps. That is why using expanded property nodes to set multiple poroperties for the same widget has an advatage since only swap is required rather than multiples. Here was a bug in a version of LV 8.X that preveeented the single thread swap. So in some cases it may be an advantage to just run the VI in the UI thread to start with. It would recieve the performance hit of having to share the UI thread, but would benefit from not havving to thread swap repeatedly.

Quoting Lul

"Is is like a sharp sword..."

Ben

[kr74i0au]

In which execution system does a top level VI run when that VI is set to "Same as caller"? Is there a way to get this information programatically?

[David S.]

Do the rules for property nodes apply to the new Class Property Nodes, too? How about DAQmx or other driver API property nodes?

[kr74i0au]

Great question David S.!

[man78]

If anyone could answer these last two questions...

[AristosQueue (NI)]

> In which execution system does a top level VI run when that VI is set to "Same as caller"? Is there a way to get this information programatically?

It runs in which ever execution thread is available to run it. There is no way to get or set this information programmatically.

> Do the rules for property nodes apply to the new Class Property Nodes, too? How about DAQmx or other driver API property nodes?

No. They apply only to *VI Server* property nodes. I edited the pptx to make that explicit.

[David S.]

Thanks, AQ. I'd like to clarify one thing: ALL VI server nodes run in a UI thread, regardless of whether they're working on a UI element or not? So if I use a node to get the "VI:Name" property in one of my error reporting subVIs, that node executes in a UI thread?

[stupidboy1121]

Wow! I didn't know that!

[Current_93]

Dear folks, what does it mean "Avoid operations which require the front panel to be in memory".  Can you explain it more popularly?  If I have one vi (from 350) as User Interface in "long-running" application. Сan anyone tell me how long the "long-running" LV's application can work on Windows 7, for example?

[crossrulz]

Current_93 wrote:

                       

what does it mean "Avoid operations which require the front panel to be in memory".

                   

The idea is that you have front panel memory and block diagram memory.  So for your subVIs, you will have better performance if you can keep the front panel out of the execution.  There will be less memory transfer and generally less memory usage.

Functions to avoid would be property nodes and libary calls that run in the UI.

[Current_93]

"if you can keep the front panel out of the execution."

How can I do it ?  

[rolfk]

As crossrulz already mentioned. Don't open the front panel or set the option in the VI Options to load the panel on load of the VI. And don't use VI Server properties that operate on any UI element. LabVIEW loads the panel only into memory when it is needed. Telling LabVIEW that the panel may be necessary to open later on, or opening it explicitedly through an Option setting or VI Server, as well as having any property node on the diagram that accesses any front panel object will always cause the front panel to get loaded.