LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
AnthonV

New in-place element structure option - class property node read/write - to ensure access to parent node private data is done in-place

Status: Completed
Available in LabVIEW 2013

I love lvoop but I hate that you have to suffer a huge performance hit when accessing parent class private data via access vi's, especially if it is large datastructures.  

 

As access vi's can also be invoked using property nodes, make a read/write property node pair accessible via an IPES - this will instruct the compiler that this access to the parent class' data should be done in-place.

26 Comments
AristosQueue (NI)
NI Employee (retired)

Actually, no... try this on for size...

 

Suppose your parent class as a data field "LargeDataBlock". Create the accessor "Swap LargeDataBlock.vi". It takes the class in AND has a class out. It has a Recommended input of type LargeDataBlock.

 

On the block diagram, do this:

SwapValues.png

Then, to use it, do this:

Untitled.png

AristosQueue (NI)
NI Employee (retired)

The swap size of any data type is its top-level size, so you can swap an array or string or path or *nested object* at the cost of just a pointer (4 bytes or 8 bytes depending upon system).

AnthonV
Active Participant

Brilliantly sneaky! And I like it as the parent vi's have direct access to the data - unlike the DVR or SEQ methods I suggested,

 

Now that 2013 is released (today) I might also try your first suggestion (accessor vi's that don't have error clusters or any case structures and ideally the read hasn't the class wired through).

 

Thanks for the interesting discussion.

 

Now back to 6th Str for a couple of beers...

 

 

AristosQueue (NI)
NI Employee (retired)

I've thought about modifying the templates for properties to have a Read and a Swap instead of Read and Write... the Property Node syntax makes that awkward since you actually want two different read properties, one for "I'm reading this and I'm not giving it back" and "I'm reading this in order to modify it and restore it", but there's no way to express that with the property node.

 

The property node syntax is really awkward sometimes... I like just using the subVIs... more flexibility to express exactly what needs to be expressed, rather than try to shoe-horn into some particular syntax -- it's like having the requirment that there's only one conpane allowed for all VIs.

AnthonV
Active Participant
I find my guys using property nodes when there are many members to read or write on the same diagram. Then it saves real estate. But I hate it when coding decisions are made because of diagram layout considerations. From our discussion above, dropping an (swap) accessor vi down instead of using property nodes would make a lot of sense when performance is a consideration. Saw some crazy bull riding last night on 6th.
Darren
Proven Zealot
Status changed to: Completed
Available in LabVIEW 2013