Static Accessor from Template has Inlined Execution

[NathanJD]

I was working with LVOOP today and was trying to create accessors for my private data and I found something that doesn't seem to make sense (and doesn't seem to work at all in some cases).

When creating my accessors, I used the "Create VI for data member access" dialog.  It was set to create "static accessors" and to allow them to be accessed via property nodes.  When I went to use these accessors via propery nodes, the code failed to compile.  It turned out that the accessor VIs that were created had their execition mode set to preallocated clone and to be inlined.  When I reverted these back to the default settings, my code compiled and functioned perfectly.

I check the actual VIT file that is being used for the template and it is set as non-reentrant.  Also, when I create accessors using the same method as above but choosing dynamic instead of static, the reentrancy is what I would normally expect, non-reentrant.  It did not appear to correlate to the "availale via property node" setting.

Is there a reason why the rentrancy of static accessors are being changed?  It is it safe to change them back to normal or do I need to be using dynamic accessors?

LabVIEW 2013 & 2015

[Skirpt]

Hi NathanJD,

I have taken a look at this and when I set the accessor to Static and allow the use of Property nodes in both LabVIEW 2013 SP1 and 2015 they both behave the same way. What I see is that the execution of both are set to preallocated clone reentrant execution. I am also able to wire the output of the class that I created into a Property node and it gives me the correct options for the class. I do not get any issues with running the code after that. 

When you say you are unable to compile you just mean that you have a broken run arrow? 

[NathanJD]

I was unable to produce the failure in a new project with a new class.  I'm not really sure what was wrong.  All I know was that to fix the issues, I simply changed it to not inlined and to be non-reentrant.  But I'm still curious if it's normal for the static accessors VI's to be inlined.

[Skirpt]

WHen you remade the project and make accessors are they still inline? If they are set to inline do you get any errors?

[NathanJD]

They are still preallocated clone and inline in the new project (2015).  There are no errors, it runs just fine.

I guess at this point I'm curious why a static accessor would be set to be inlined.  I was not expecting to see the execution settings change since it was based on a template.

So, if this is normal behavior then I'm happy to close the topic.

[Kyle97330]

It was probably done as part of NI's perpetual quest to make LabVIEW run faster.  Inlining any given VI removes the overhead associated with calling a normal SubVI, and since it's a static accessor it wouldn't need to check and see which descendant VI to run after it's compiled.

In casual code the difference is negligable but if you throw a class accessor in a loop and read/write to it a million times you'll start to notice the difference when it's inlined.  

I don't know about you, but 99% of the time I never need to do any of the things in an accessor VI that can't be done to an inlined VI...

[NathanJD]

That's the only reason that I could think of myself.  I agree that most of the time, they can be inlined.  I was first thinking that you might want to override an accessor but at that point it would probably be considered a method rather than a property (other than property node access, there really is no technical distiction between the two in LabVIEW anyways).

[Kyle97330]

I have on certain occasions used overrides on accessors to make them effectively "read-only".  

For example, if I'm using a class as a hardware abstraction layer, I'll often have a variable in the top-level class that describes a feature that might or might not be present on a child class.  For any given child class, having that feature could either be "always yes", "always no", or "depends on <model number/attachments/firmware revision/other>".  If it's one of the two "always" options, I'll override the "Read" accessor with a hard-coded True or False constant.  

Maybe it's a pointless distinction because at that point it's dynamic dispatch and the inline question is moot... but just because an accessor stops becoming a strict property read doesn't mean it becomes a method.