Front Panel Object Memory Explosion

[GregR]

DVRs are cleaned up when the top level VI stops running. Their data is disposed at that point and will not be reported in any of the numbers in Properties. Also control values are not counted as part of the Front Panel number. They are counted as part of Data.

The Front Panel number relates to the size of the objects that define the controls themselves. A numeric is not that big. A graph has a lot of parts and is larger. The growth you are seeing really comes from another aspect though. Undo information is included. Every time you edit an object on the panel or diagram, we remember its previous state so we can undo. This results in continued growth in memory until your maximum undo steps is reached. When we save, we do not save the undo information so the next time you load it is back to its original size. This points to another clue that this is the behavior being seen. The "Total VI Size on Disk" is small even in the 30MB fron panel case.

Unless your machine has little physical RAM I wouldn't expect undo information to have a significant performance impact, but perhaps it does in your case. You can reduce the number of undo steps in the Environment options. See if that makes a difference.

[FlamingYawn]

I have 32GB RAM, so I don't think that's the issue.

I'll try reducing my undo steps and see if that makes a difference.

Doesn't "Undo" cross save boundaries now?  As long as it's still in memory?

Does that explain why the front panel memory usage doesn't redunce when I save the VI?

[GregR]

---

@FlamingYawn wrote:

Doesn't "Undo" cross save boundaries now?  As long as it's still in memory?

Does that explain why the front panel memory usage doesn't redunce when I save the VI?

---

You are correct. Just saving keeps undo in memory. Unloading the VI will deallocate it.

[altenbach]

---

FlamingYawn wrote:

Doesn't "Undo" cross save boundaries now? 

---

This feature got implemented in LabVIEW 2011 based on this idea. 🙂

[BigShotEngineer]

I am also having a similar problem.  WHen i first load up the VI's front panel, the memory usage shows ~700K.  I have tabs on my front panel.  Just flipping through a few of the tabs and the VI properties memory usage shows ~2600K.  I started noticing a slow down in responsiveness.  Keep in mind i have not yet hit run.  I'm just clicking on the tabs to view them in "edit" mode.  Then I clicked on each one of the tabs and i'm now at ~16000K.  I clicked around even more and now i'm at ~25000K, and the FP is soooo sluggish.  SLuggish in terms of the time it takes from clicking on the tab, to the time it actually displays the tab contents. 

The sluggishness propagates to "run" mode too.  

This started happening after I replaced some stuff on the front panel to Silver style (from Modern). And i also grouped everything in each one of the tabs.  Does grouping items on the front panel have an issue? What about silver style controls? 

Luckily, when i close out and reopen the VI, i'm back down to ~700K.  If i immediately run my VI everything is speedy.  I guess i will have to just run it close out and reopen to use my VI after i do my edits.... it shouldn't be like this right? I wish I could share my code, but it is confidential.  

[mikeporter]

Yet another problem caused by tabs. Apparently each page change doesn't register an one change to be undone, but many.

Mike...

[RavensFan]

I wouldn't consider this a tab control problem.  I'd consider it a problem with the undo history function.