11-05-2018 04:28 AM - edited 11-05-2018 04:40 AM
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).
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).
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).
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?
11-05-2018 09:22 AM
Maleable VIs are inlined; so each instance is a copy, not a reference to a single VI.
11-05-2018 01:45 PM
@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...
11-06-2018 01:17 AM
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):
Size on disk with malleable SubVI
The malleable function memory usage is following:
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.
11-06-2018 06:55 AM
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.
11-06-2018 07:36 AM
If I'm not mistaken, when you drop a .vim on a block diagram, what it does is: