Hi all,
we're currently thinking about a concept of how to implement a component-based / OOP-like concept for a test program.
The target is to have a component which has a defined interface for functions provided to other VIs
and a method to store private data inside the component. I think of something like a C++ class without using
the GOOP toolkit, because I don't want to depend on a toolkit for such generic functionality.
From our point of view there are currently three possible ways to do this. If you are willing to read all the text below
please tell me which one would be the method of your choice.
Of course, other approaches or comments are highly welcome... 😉
1) Using queues as private data storage
This approach has a one-element queue inside the component, containing a cluster with the private data.
If a function wants to modify or read the private data, it empties the queue, modifies the data
and writes the data back to the queue. Because the queue is only one element deep the private data
is automatically protected against shared access while being modified.
The question is how much performance and memory overhead does the use of queues in LabVIEW really have?
I thought that a queue would require three times the memory space of the data it contains: first
when the data is put into the queue, second to hold the data inside and a third time to read the data
out of the queue.
With a simple test VI we see that only twice the amount of memory is needed and the
question is why ? Is LabVIEW smart enough to optimize the memory usage in this special one-element queue case
or is my 3-times approach somehow wrong ?
The advantage of this solution against 2) is that one can split the component in several VI's with a different
connector pane to have a cleaner and more intuitive interface of the component. But what about the degree in
performance when using queues ? Is this not worth to mention on today's machines (This component has no time-
critical functions by the way)?
2) Using Uninitialized Shift Registers
All functions of the component are in the same VI, which has a while-loop with an uninitialized shift-register
which holds all private data in a cluster . This is the way as described in Conway & Watts
"Software engineering approach to LabVIEW".
I think that the main disadvantage is that all functions of the component have to share the same interface, which means
that the interface has to be very generic. Further from our measurements with the VI profiler we see that this solution
requires three times the memory space of the private data, while I thought this should use only two times the memory amount
of the private data size.
Additionally internal, private subVIs of the component accessing the private data would require the private data wired through them.
This leads to a general question if passing data to a subVI and back requires a copy of the data or not, if no other modifications to the data are made during the subVI call?
3) Using LabVIEW 2 globals
This approach is maybe basically the same than 2), except that the USR holding the private data is in an extra subVI.
This way it is not necessary to route the private data cluster through internal private subVIs. Does it cost memory
and performance to access LV2 globals or is LabVIEW in this case smart enough to optimize LV2 globals, too ?
Many thanks in advance
Conni 😉
