LabVIEW Development Best Practices Documents

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW Performance and Memory Management

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
Elijah Kerry
Chief Product Manager, Software Platform
_______________________________________________
Follow my Software Engineering for LabVIEW Blog
Comments
Active Participant TroyK
Active Participant

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.

Troy - CLD "If a hammer is the only tool you have, everything starts to look like a nail." ~ Maslow/Kaplan - Law of the instrument
Member WG-
Member

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".

Active Participant LuI
Active Participant

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!

Knight of NI Knight of NI
Knight of NI

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

Member kr74i0au
Member

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.
NI Employee

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

David Staab, CLA
Staff Systems Engineer
National Instruments
Member kr74i0au
Member

Great question David S.!

Member man78
Member

If anyone could answer these last two questions...

La théorie, c'est quand on sait tout et que rien ne fonctionne.
La pratique, c'est quand tout fonctionne et que personne ne sait pourquoi .
(A. EINSTEIN)
Proven Zealot
Proven Zealot

> 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.
NI Employee

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?

David Staab, CLA
Staff Systems Engineer
National Instruments
Member stupidboy1121
Member

Wow! I didn't know that!

Member Current_93
Member

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?

Not applicable
Knight of NI Knight of NI
Knight of NI

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.


There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
Not applicable
Member Current_93
Member

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

How can I do it ?  

Proven Zealot Proven Zealot
Proven Zealot

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.

Rolf Kalbermatter
Averna BV
LabVIEW ArchitectLabVIEW ChampionLabVIEW Instructor
Contributors