LabVIEW
LabVIEW Memory Allocation Question
Myself and a coworker were participating in a peer review this morning and came across the following question. My preference is to leave my controls unwired and outside of my main loop for easy access when opening the block diagram. Like so:
I do this as an easy way to create property nodes, local variables and to have general visibility in my block diagram. Again, this is purely personal preference and probably isn't the correct way to do things in NI's style guide. My coworkers theory is, if I leave the controls unwired outside of my loop, there is an extra memory space created for the associated local variable. My theory is, there is not going to be an extra memory space in an .exe because of LabVIEW's dead code elimination in the compiler. Who is correct?
I believe that your coworker is correct. You have a copy of the data that you are displaying on the screen and another copy that you are using in the code. I personally see this as an easy way to create race conditions in the code. I rarely use local variables, and property nodes are used sparingly. I would personally see this as clutter on the block diagram that makes it harder to follow data flow.
@FakeName_ wrote:
I do this as an easy way to create property nodes, local variables and to have general visibility in my block diagram. Again, this is purely personal preference and probably isn't the correct way to do things in NI's style guide. My coworkers theory is, if I leave the controls unwired outside of my loop, there is an extra memory space created for the associated local variable. My theory is, there is not going to be an extra memory space in an .exe because of LabVIEW's dead code elimination in the compiler. Who is correct?
Obviously you come from a text based code background and and have a habit (good for text, bad for graphical!) to define "variables" to be used everywhere (via local variables and value property nodes, blech!!). There will be extra memory, an increase risk of race conditions and even extra expensive thread switching.
LabVIEW has no "variables", simplified you can think of it as "the wire is the variable". Terminals are to communicate with the user (read controls, write to indicators), not to store data. Terminals have their own memory copy as well as a transfer buffers that holds the data until the UI thread can update the front panel.
A terminal belongs to where is is used! From the wiring and data dependency you can easily follow where the data is coming from and where it is going and what depends on what. Scattering locals and value property nodes all over the diagram breaks all dataflow dependency causing race conditions that you then need to fix with excessive amounts of sequence structures (double blech!!!). This kind of programming greatly reduces code readability.
Don't forget latch action boolean controls. After being operated by the user to the non-default state, they will reset back to the default state once the terminal is read by the code. If the terminal is outside you code, it will be read exactly once at the start of the program and then never again. This also means that when you press it during run, it will never reset!
Dead code elimination is not specific to executable but happens always, in fact LabVIEW is always compiled instantly on the fly as you edit. Building an application recompiles of course, but just to the new specification as defined in the builder (e.g. disable debugging, etc.)
