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

[AnthonV]

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.

[AristosQueue (NI)]

Inline your data accessor VIs. This will suffice as of LV 2013 so long as your read and your write are at the same diagram level (i.e. if you had an inplace element structure, its unbundle and bundle are both within the same structure... if your read and write VIs are also within the same structure, the parent access will be inplace).

[AristosQueue (NI)]

I should also say... for large data structures, your parent often shouldn't be exposing accessors for the whole data structure. The parent is generally responsible for maintaining the coherency of that data structure and so should be handing out protected methods to do specific operations, not general read/write methods. This by no means always true, but it is often true.

[AnthonV]

Yes I have several cases where the functionality cannot be known at the design time of the parent class, and the particular child class would implement the unique function that it requires to perform (on the parent data). 

Thanks for the tip however I have tested what you suggested and I cannot reproduce it on this side.  I am running 12.0.1 (32bit) which is 2012 service pack 1.  This is the 2013 you are referring to?

Have a look at the small attached example of this.  Is there a way to attach a file to this post then you could run it to check?

The parent uses direct unbundling of its private data (super fast) and the child uses the in-line access functions (veeery slow).

Let me know if I'm missing something obvious (has happened before).

[AristosQueue (NI)]

No. LabVIEW 2013... releases in August of this year. Not yet shipping.

[AnthonV]

Seems it WAS something obvious that I was missing afterall:  2012 is NOT 2013.  I'd be very keen to test this when the new version is released.  This will solve my problem and remove the need for the new IPES structure I expect.

Do you know if nested access functions would also be recognised by the compiler (say if the parent's data I am accessing is itself a class and I want to in-place access some of this class' data.  It might work as long as it is all in one frame I suppose?

[AristosQueue (NI)]

AnthonV: Close your eyes and imagine what your diagram looks like with the subVI nodes replaced with their contents. Repeat this for every layer of inlined subVIs. If after all that the result is a single Unbundle Node that, in the same structure bounds, is connected to a single bundle node, then, yes, it will work.

[AnthonV]

Thanks for that description. I often close my eyes and imagine my LabVIEW diagrams - this is normally just before my boss walks into my office.

[AnthonV]

Two questions though -

1) would it matter whether the accessor function has its unbundle or bundle inside a case statement selected by the error input cluster?  I heard somewhere that the bundle or unbundle should NOT be inside a case statement for this to work.

2) would it matter whether the accessor function is also accessible via property nodes? I see selecting the property node option automatically selects the creation of error terminals and the error case selector.

[AristosQueue (NI)]

> 1) would it matter whether the accessor function has its

> unbundle or bundle inside a case statement selected by the error input cluster?

Yes. If it is in a case structure, all the inplaceness is blown away. It has to be an unconditional read followed by an unconditional write.

> 2) would it matter whether the accessor function is

> also accessible via property nodes?

Yes because property nodes add error case structure. If you turn off the error handling on the property node, I'm honestly not sure what happens. If you use the property node to access more than one property at a time, that would also blow it away.