LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Malleable VIs - big memory consumption and loading time issue

Have anyone using malleable vi's encountered a problem with big memory consumption and/or loading time?

Take a look at the attached malleable memory check.vi the vi consists of a numeric constant and 8 instances of Is Value Changed.vim

It consumes 144KB of disk space (see 1.PNG).

1.PNG 

Just by removing the Is Value Changed.vim from the BD or replacing it by other primitive (like increment) malleable memory check.vi reduces the size to around 3-5KB (see 2.PNG).

2.PNG

The only logical assumption would be that the whole Is Value Changed.vim is placed 8 times inside the calling VI (8 * total size of Is Value Changed.vim).

VC1.PNG

That wouldn't make much sense at it should contain only compiled code of *.vim.

This is a real problem as I am instantiating hundreds of *.vim's in my top level VI and this way it reaches dozens of MB without any reason.

It was much smaller using the polymorphic vis with the same functionality as *.vim.

Any remedy or suggestion on this?

 

Download All
0 Kudos
Message 1 of 6
(2,650 Views)

Maleable VIs are inlined; so each instance is a copy, not a reference to a single VI.

"If you weren't supposed to push it, it wouldn't be a button."
Message 2 of 6
(2,634 Views)

@graPI wrote:

 

This is a real problem as I am instantiating hundreds of *.vim's in my top level VI and this way it reaches dozens of MB without any reason.

 

 


Dozens of MB are typically not a problem. Do you have performance issues? The VI size on disk is not important at run time and as you can see, the "code" is only a few Ks.

 

LabVIEW 2018 here, but if I create a similar malleable VI as follows, the subVI is larger, but the caller with 8 embedded instances is slightly smaller on disk. Go figure. 😄 YMMV...

 

MallSize.png

0 Kudos
Message 3 of 6
(2,607 Views)

Thank you for the answers.

I understand that the malleable VI are inlined and as such have to add some memory to the caller but why so much?

Why not only the size of the compiled code? 

It is also clear that it is the size on disk and not the RAM during operation but for a repository it is beneficial to keep the files small.

 

Consider the following (real life) example.

There is a group of 17 "top level VIs" calling particular function.

To be precise the total of 113 instances of this function.

 

Size on disk with inlined Polymorphic SubVI call (sorry for Polish language inside images, this screen from windows directory properties showing size, size on disk and number of files):

inline.PNG

Size on disk with malleable SubVI

malleable.PNG

The malleable function memory usage is following:

function.PNG

 

To sum up the problem:

The operation speed is OK

The RAM consumption is OK

The size on disk is totally Not OK, especially for files in repository (I would expect to have only the 4,5K of compiled code of the malleable vi to be added to the callers while it is rather the total ~146,1K content of malleable vi placed inside callers)

LabVIEW project loading time is increased (no precise measurement for this though).

The same problem is there for LV2018.

0 Kudos
Message 4 of 6
(2,568 Views)

All that follows may be flawed and incorrect.  I've only used vims in LV 2015, so much may have changed, have never been true or by some fluke might just happen to be correct.

 

Malleable VIs are inlined. They create a full copy of the original VI (and as such is actually no longer linked to the original VI).

 

The need to save the entire VI as opposed to just the compiled code is that you may change the datatype of the input and then the VI will need to re-adapt.  In order to re-adapt, it requires more than the code created last time because of the type specification structure's ability to completely do something else based on which datatype is wired.  Of course this begs a question....Why don't Malleable VIs just link to the actual master VI instance as opposed to making a full copy? I don't know, there may be a technical reason behind that but I'm unaware of the details.

0 Kudos
Message 5 of 6
(2,538 Views)

If I'm not mistaken, when you drop a .vim on a block diagram, what it does is:

  1. Places a sequence frame on the BD.
  2. Copies the .vim's BD into the frame, replacing the control terminals with tunnels on the frame.
  3. Sizes the frame to 32x32.
  4. Pastes an image of the .vim's icon on top of the frame.
"If you weren't supposed to push it, it wouldn't be a button."
Message 6 of 6
(2,527 Views)