Front Panel Object Memory Explosion

[FlamingYawn]

LabVIEW 13.0.1f2

After several minutes of editing the logic of a SubVI, I noticed the development environment slowing down.  I checked the memory usage of the VI, and noticed 30+ MB of Front Panel Objects.

When I remove the VI from memory and reopen it, the Front Panel Object memory is back to normal.

This has happened three or four times now with several VIs in this project.  I haven't ever been modifying the front panel objects, which consist of a DVR in and out, as well as a boolean and small cluster.  I've worked on similar VIs in the same project in every version since 2011 and only started seeing the problem in 2013 SP1.

Has anyone seen similar behavior?  Any explanations?  What all is going into "Front Panel Objects"?  I could understand the high memory usage if I had a bunch of data in an array control on the front panel, but all I'm doing is editing logic without even running the VI.  Is undo history stored in this memory?

[altenbach]

Ouch. somebody from NI needs to look into this....

[Matthew-B]

Hi Robert,

I have observed the same memory usage behavior in LabVIEW 2013 SP1 that you are observing when you edit just the block diagram. I've done some experimentation and research and have located some information that hopefully explains some of what we are observing.

I started with a VI that I've written and moved a few things around the block diagram (I also tested the case of modifying the logic, but I was able to observe what you were seeing just by moving objects). The Front Panel Objects memory usage increased. The memory usage would continue to increase as I made changes until I closed the VI and reopened it. To see if the undo feature had effect on this, I changed the maximum number of undo steps in the LabVIEW Environment options to 1 rather than the default 99. This resulted in a much smaller Front Panel Objects memory usage compared to the case of 99 undo steps stored in memory. The VI Memory Usage LabVIEW help page mentions that using the undo feature creates temporary copies of objects. It also mentions that if you save the VI, it purges these copies but it only appears to purge the copies that you've already undid (the ones that would come back if you click redo).

The increased memory usage looks like it is the expected behavior, but I'm not sure why this increased memory usage would cause your development environment to slow down in LabVIEW 2013 SP1. I tried the same steps I did above in LabVIEW 2011 SP1 and observed the same memory usage behavior. I apologize if you mentioned this already (I wasn't clear), but does the slowdown happen with multiple VIs open or does it only seem to happen with one particular VI?

Best Regards,

[altenbach]

Even the 1MB FP use for the fresh VI seems rather high for what you describe. Are you sure there is not some hidden data?

[FlamingYawn]

The DVR references a large cluster; that's probably why the initial memory is as high as it is.

The dev environment only slows down when making changes to that particular VI.

Why would undo create copies of front panel objects when all I'm doing is adding logic?

[JÞB]

Just a wild thought.  You don't have "Retain Wire values" on by accident do you?

[altenbach]

---

@FlamingYawn wrote:

The DVR references a large cluster; that's probably why the initial memory is as high as it is.

---

Well, a DVR is just a tiny reference. It does not contain the cluster data.

(The "retain wire values" mentioned by Jeff is an interesting possiblity.)

[FlamingYawn]

"Retain Wire Values" was not on, but that's a good thought.

Even though the DVRs are just references, they must store the referenced data.  When I delete them and reopen the VI, the front panel memory drops from ~1000k to ~17k.

[altenbach]

---

FlamingYawn wrote:

Even though the DVRs are just references, they must store the referenced data.  When I delete them and reopen the VI, the front panel memory drops from ~1000k to ~17k.

---

That does not make any sense. DVRs retain only a single copy of the data in a central location to be accessed from anywhere, so why should the connecter contain data??? How big is the actual DVR data (e.g. flatten it to a string and measure string lenght).

MAybe something was corrupt. Does the size increase again if you add the references back?

[FlamingYawn]

DVR cluster is 1718 bytes flattened.  Front panel memory goes back to ~1000k when I add the DVRs back.

When the code is compiled I'm sure the DVR is just a pointer.  In the dev environment, however, it needs to know all the data types in the DVR as well as their names, etc., so you can bundle, unbundle, for use in an in place node, etc.

Program execution memory and dev environment memory are two separate cases.