Only the specific instance being invoked of a polymorphic VI should be loaded into memory.

[InternationAL]

I searched on "polymorphic" and did not find this idea posted. 

I just learned over here that when you use a polymorphic VI, all flavors of that VI load into memory!  That's why a VI hierarchy gets so cluttered so fast when you use them.

In the object-oriented version of polymorphism, all possible polymorphic cases need to be coded and loaded into memory, since any of these possible cases could be called depending on the execution of the program.  In the LabVIEW-specific version of polymorphism, where a function has many flavors, perhaps due to a change in data type on one of the inputs, it is not usually the case that all of the different polymorphic members can execute at run time.  In fact, I believe it is usually the case that only ONE of the cases will ever be called or execute.

So, why are all of the other polymorphic members in memory?  I don't know.  I think they shouldn't be.  They seem to be eating RAM for no good purpose.

Load only the specifically called version of a polymorphic VI into memory.

[AristosQueue (NI)]

We have discussed doing this many times, but we generally run into a problem. When you wire a new wire to the poly VI node, how do we know which instance we can pick unless the conpanes for those instances are loaded into memory? Yes, we can read ahead those conpanes out of the VIs on disk without actually loading those VIs, but do we do that on every mouse click on your diagram? Or do we cache those conpanes, at which point we may discover that the VI on disk has changed between when we originally cached it and current. 

The bookkeeping required is extensive, especially with more people using source code control where they may very commonly revert a bunch of changes, thus overwriting the file on disk without LV noticing. We're working on improving that, but other features that we're considering -- that would make user VIs more polymorphic -- may require us to have the entire VI around anyway. 

So, no, it isn't a waste of RAM. It is exactly what makes the editor environement work. We don't load all the instances in the runtime engine or when deployed to targets. 

[TCPlomp]

However it is not a waste of RAM, it limits the usage of polymorphic VIs.

For instance, version 3.0 of the OpenG array toolkit was epxanded with support for the LabVIEW object.

This was implemented in a polymorphic member.

Now if we drop the polymorphic VI on a RT target the owning VI is broken while there is no explicit need for that.

See here with such a problem.

Ton

[AristosQueue (NI)]

> Now if we drop the polymorphic VI on a RT target the owning VI is broken while there is no explicit need for that.

That won't be a problem much longer...

[TCPlomp]

That is the wrong order.

We could prevent such items for any kind of datatype and polymorphic VIs by only loading the actual instance.

What if there comes a new datatype that is only supported in the MAC OS, any polymorphic VI developed on the Mac with such a datatype instance will break any Windows VI calling that polymorphic VI.

That is a bad design IMHO.

Ton

[Darren]

Any idea that has received less than 8 kudos within 8 years after posting will be automatically declined.