Is a DVR a good way to prevent the performance hit when accessing LARGE parent class private data from a child class?

[AnthonV]

I love object orientation in LabVIEW.  It has made my code hugely more maintainable, readable and extendable.  However, I hate the MASSIVE performance hit you take when you access large parent private data through access vi’s.   Public data would be one way to solve this.

There is no way I can see to tell the compiler that I want to access the parent’s data in-place and from my tests the compiler isn’t smart enough yet to see these patterns across vi boundaries.

I often run into this – huge datasets are encapsulated in a parent class, and varying functionality is encoded in child classes.  But these child classes have to access this parent data.  If this data is several megabytes even a simple array element replacement can take several milliseconds where it should be nanoseconds.

I’m getting around this by not having the actual data (say a 10million element array of doubles) in the parent class’s private data control, but rather a DVR to this array that I create in the parent class’s constructor. 

Then the child class can access the data via the DVR (the parent class has access vi’s for the DVR).   It still isn’t as efficient as directly accessing the data but close nonetheless. 

The down-side is that the parent class also now only has access to its own data via this DVR – this makes the parent class’s vi’s slightly more bulky but this is acceptable. 

If anyone has any comments or suggestions on better ways to access the parent class’s private data in-place please post here.

[CMal]

One other approach you might take is to use inlined accessor VIs.  Make sure your parent's "get" and "set" VIs are inlined, and that they do not contain case structures surrounding the unbundle and bundle nodes.  This may allow LabVIEW to optimize the code as if the data were public to the child class.  I've never tried this myself with large data members, so I cannot guarantee that it will help, but it might be worth trying.

Chris M

[AnthonV]

Thanks for the tip Chris.  Some time ago I read this same advice and tried it but unfortunately speed tests don't show any improvement.  

Incidentally these days creating an accessor vi from the drop-down menu automatically ticks the 'inline' option and as long as you don't select that you need to 'include error handling terminals' then by default no case structures exist in the 'get' and 'set' functions.

Thanks though - any other alternatives to the DVR I proposed above? I suppose Single Element Q's would be another way or maybe even a variant, but all are a roundabout ways of doing it.

[tst]

A variant would create a copy and a SEQ is essentially the same as the DVR, so you might as well keep the current code.

One option I thought of is to have the parent unbundle the data and then call a DD VI to operate on the data, but because of the dynamic nature of the DD VIs, I'm not at all sure the compiler can do that in place (i.e. if inplaceness has to be set statically, you can't set it if you have an unknown set of VIs).

I think overall the DVR is a decent option if inplaceness is important to you.

[AnthonV]

Tst you know this isn't the answer I was fishing for when I posted, I was hoping that there is a tickbox I missed that either states

1) 'make specified data public to child classes' or

2) 'let compiler recognise property node read and write pairs as inplace operation'

Option 2 seemed to make sense as this is what we used to do before the inplace structure - unbundle followed by bundle was recognised as inplace if you kept to a couple of unwritten rules between then and used the 'show buffer allocations' refresh button often.  With the ability to make the access functions available as property nodes, maybe this might be a way to do it without breaking the lvoop encapsulation decisions.

In fact, come to think of it there should be an additional in-place element structure called 'class property node read/write' that does exactly that.

Is there an niweek session that might be discussing these types of issues (inplaceness and performance on large datasets)?

[tst]

Option 1 is a definite no and as far as I know it has been NI's explicit intention to steer clear from it. I believe there's an idea in the IE which asks for this.

I agree that option 2 makes sense, but I don't think it should be something the user specifies. Either LV can detect it automatically or it can't, but I doubt NI would let you have an option which creates the possibility for this kind of bug.

I'm not sure, but the mark as modifier option on the IPES might be the option you're looking for. I know that it exists and I know very roughly what it does, but the documentation for it is very limited and I never actually played around with it, as usually I don't need these kinds of optimizations.

You may well be right that a new option on the IPES is desirable and you should probably add it to the idea exchange.

As for NIWeek, I'm not going this year, so I have no idea what kinds of sessions are around, but it's a great place to find people who know what they're talking about and ask them about it directly. Certain people in LV R&D would probably be ideal for this and if you ask relevant people, you might even get their names. I'm sure buying them a beer would also help to loosen their tounges. If you ask me, this type of interaction is the main value of the conference, not the sessions themselves.

[AnthonV]

I'm not very clear on the intention of the 'mark as modifier' option on the IPES but I'll have a good look at it and report back.  

I've never tried putting something on the idea exchange but I'll give it a go with the new IPES option, what's the worst that can happen?

As for NIWeek, I'm looking forward to meeting some of the right people there so I'll start asking around for leads.

Thanks for the thoughts.

[AnthonV]

Just to finish off this thread - here is the conclusion of this discussion on the Idea Exchange (several options for efficiently accessing large parent data is given here):

http://forums.ni.com/t5/ideas/v2/ideapage/blog-id/labviewideas/article-id/23924

[Yamaeda]

G# uses DVR for object memory as standard, we've never noticed any big performance hit, although i dont know how big object memories we've used. Maybe worth a look?
/Y

[AnthonV]

G# - Looks interesting. Its free - but what's the catch?

It doesn't list RT as a supported operating system; its probably a safe assumption that they are referring to the supported OS in terms of the IDE and not the target?

However asking me to part with my existing classes is like asking a mother to give up her children...