Why closing type definition uses so much memory and is so slow

[jacemdom2]

I sometimes load 4000-5000 VIs in memory. Memory usage when just loaded 536MB. If i open and close the front panel of a highly used Type Defintion, it takes around 30 seconds, the cpu usage goes to 100% and the memory jumps to 2309MB. Why is it doing this? Is this due to some sort of compiler issue that forces to open a reference to every caller of the type definition?

[crossrulz]

Depending on what you did to the type def, it is likely part of the allowing you to check the default values.  Find a place where your type def is used, right-click on it, and choose "Review and Update From Type Def...".  It will ask you to go through any non-standard default values used by that type def.  I assume that once those are cleared out, the memory usage should go back down.

[jacemdom2]

There are no modifications involved.

1- Open LabVIEW

2- Load all VIs in memory

3- Open TypeDef front panel

4- Close TypeDef front panel

When closing TypeDef cpu usage very high for 30 seconds and memory jumps. Really looks like LabVIEW is opening references to every caller VI.

I am using customized controls so i tried it with standard controls, samething. Changed from Strict Type Def to Type Def, samething.

[RavensFan]

Why did you create another username?

[jacemdom2]

For some unknown reason i can post on any boards except LabVIEW. Lili McDonald (community manager) is currently investigating the issue. I figured it would be easier and faster to create a second account until the issue is resolved. I get "An unexpected error occurred." everytime i try to create a new post on the LabVIEW board. I can reply to posts but cannot initiate one???

[natasftw]

I'm not sitting in front of LV at the moment.  Open up a blank VI.  Add your typedef as a constant to it.  Save the VI.  Open the typedef and take a look at the constant.  Does it get greyed out immediately or wait until you make changes?

If it gets greyed out, it wouldn't be surprising if the link to these typedefs are being updated.  I doubt anyone expected you'd open 4000-5000 unique instances of this typedef rather than pass data into subVIs.  It's likely there is some overhead related to updating all of the links.

[mikeporter]

Can you describe the typedef in question?

Frankly, to me this sound like a problem caused by a fundamental programming error. 4000 to 5000 VIs? I have seen many really large applications that had only a 1000 or so.

Is the application using any sort of standardized structure or framework?

Have you tried doing a forced recompile and a Save All?

Have you verified that none of the VIs are read-only.

Mike...

[jacemdom2]

Let me try to reformulate and clarify.

I have multiple projects consisting of hundreds to thousands of VIs, SubVIs, TypeDefinitions, "SubTypeDefinitions". All of those projects share a library of around 2000 VIs, accumulated over the last 18 years of fulltime LabVIEW development. In order to facilitate the update on some pieces of code used extensively, i use a "tree vi", a VI with references to all the top levels, dynamic or not, VIs of my repository. This way when i modify a typedef used by multiple projects, i don't end up with broken code. When i do modify an extensively used typedef in can take a long time to compile and save, but that is not the issue here. Actually i have multiple "tree vis", one per project and a master one for all projects. I can recreate the issue with all of the tree vis, but as expected the issue is bigger with the master tree.

So when i open this master tree VI, all the repository used code gets loaded into memory and the ram usage goes up to around 500MB. The TypeDef i am talking about is one of the dependencies of multiple projects and is a simple cluster of 2 numerics. This TypeDef is used as an input and output on tens of VIs and also as a "SubTypeDefinition" in a couple of other Type Definition clusters that are also used in tens of VIs, also maybe used in classes did not verify. If i just open the TypeDef control, nothing happens. The issue arises when i close the control, LabVIEW hangs and cpu usage goes high for about 30 seconds during wich the memory usage rises to about 2GB.

Basically, no modifications, no unupdatable instances to review, no greyed out constants, no standardized structures or frameworks, no read-only VIs, only carefully structured hierarchical code forced saved regularly.

I have built a small example to illustrate the phenomena. Attached under fvi_lib_vi_bounds_get (LV2015SP1).zip

1- Close LabVIEW

2- Open fvi_lib_vi_bounds_get.vi and wait for LabVIEW ram usage to stabilize (around 30 seconds to reach approx 53,252 K in task manager)
3- Open std_lib_number_rectangle.ctl (very small ram increase 53,408 K)
4- Close std_lib_number_rectangle.ctl (ram increase to 73,860 K)

5- GoTo 1

This example of 21 VIs does not show the high cpu usage for 30 seconds when closing the type definition, but the ram increase is clear. From my experience the slowing only becomes annoying with hundreds of VIs and more so with thousands. I am trying to increase my knowledge of the innerworkings of LabVIEW to allow me to build more robust and efficient code.

So why the memory increase on closing?

[Sam_Sharp]

Opening up that many VIs in memory is probably going to cause some problems - if the type-def is shared amongst all of the VIs, then anything that marks it as modified (when it greys out on the front panel/block diagram) is probably doing something in the background (e.g. 'undo' as all VIs get modified, loading all of the dependencies in memory, calculating differences in default values or something like that - although you've mentioned that some of these might not be the case).

You should probably have a look at putting your code re-use library into something like VI packages - split the 2000 VIs into functional 'groups' and make a VI package for each one. You can have package dependencies (e.g. for your basic libraries/building blocks) - we moved away from having a big monolithoic reuse folder to VI packages and we'd never look back.

[Yamaeda]

Are you also using project files? I've had similar problems with them, but just using the VI Tree works better.

/Y