History of Deleted Chart is Never Freed? (Empty VI Containing 160MB of Phantom Data)

[LLindenbauer]

Dear all!

While trying to troubleshoot a slow graph* (c.f. https://forums.ni.com/t5/LabVIEW/XY-Graph-slow-in-response/m-p/4091328#M1178136), I noticed that the graph history length dramatically impacts memory usage.

I noticed that the graph had a very large allocated history buffer, leading to memory errors when copying it to a new vi and trying to manipulate it. The history buffer seems to be allocated and summed into the "Data" category for VI memory use.

The rather unexpected thing is that this buffer seems to stay allocated, even after the graph is deleted. I have attached a vi where I allocated such a buffer so that is would take up 160MB and then deleted it. The result is a VI that is empty, but still allocates the buffer for the graph that is no longer there.

This ghost memory is also generated when copying the graph via Ctrl-dragging with the mouse: After copying, the Data usage is tripled - two thirds for each copy and one third probably for a copy-ghost that will then reside in the VI. If the VI is saved an reloaded, the memory required for the ghost will be freed again, but that does not happen if the element was deleted completely.

I have attached such a VI, created with LV2016 (32). Opening it requires 160MB of RAM (see the picture above).

Apart from this, I am still trying to figure out why one of my charts is slow to update, to the point where using a tab control hangs the system for several seconds until the chart is displayed. Updating while it is not in view does not impact preformance. Copying the chart to a new VI and filling if there does not reproduce the problem. Disabling the input solves the performance issue, but defeats the purpose of the chart. All hints on how to troubleshoot this are appreciated (I cannot supply the VI containing the chart).

PS: I realize that using a graph to store data is not a good idea and neither is a large history size a substitute for proper storage and display management.

Best Regards, Leopold

[RavensFan]

It sounds like you are doing this in edit mode?

It makes sense.  If you delete something, it is holding onto it in memory in case you want to undo the delete.

And if you are doing a copy/paste or cut/paste, the same things since the data is part of the entity, it is going to copy the history data over as well.

I don't know why you supplied us an EMPTY VI.

[LLindenbauer]

---

@RavensFan wrote:

It sounds like you are doing this in edit mode?

It makes sense.  If you delete something, it is holding onto it in memory in case you want to undo the delete.

And if you are doing a copy/paste or cut/paste, the same things since the data is part of the entity, it is going to copy the history data over as well.

I don't know why you supplied us an EMPTY VI.

---

The ghost memory usage is about edit mode. Perforance problems are in run mode. I cannot show an example of the performance problem but am interested in things I could try.

I have attached the (seemingly) empty VI because it exhibits the memory problem I described. The memory allocation persists after saving the vi, closing LabVIEW and opening the VI again. When I download the empty VI and open it in LV2016, the VI takes up 160MB of RAM, as shown in the VI properties (c.f. the screenshot) and also evidenced by system memory usage. I can do the same procedure to generate arbitrary memory usage (tested up to about 1GB).

Is this not so in other versions? When will LabVIEW decide that the deleted chart can no longer be restored and will no longer allocate the memory?

[RavensFan · Accepted solution]

I don't have LV 2016 installed to be able to open it in that.  But when I opened that VI in LV 2020. memory usage was a 6.7 kB.  Size on disk is only 4.8 kB.  So there is no way I'd expect it to jump to 160 MB by opening it because I can't see it making up memory out of nothing.

There is an edit history.  LabVIEW default is 99 actions.  (Tools >> Options >> Environment).  You can actually make that smaller.  I bet once the chart delete moves out of the Undo history, it shouldn't need to hold on to that memory for the chart data anymore.

The only way I know of for LabVIEW to save the history beyond a Save, Close LabVIEW Reopen is if you happened to have saved the data for that chart as default.

[LLindenbauer · Accepted solution]

---

@RavensFan wrote:

I don't have LV 2016 installed to be able to open it in that.  But when I opened that VI in LV 2020. memory usage was a 6.7 kB.  Size on disk is only 4.8 kB.  So there is no way I'd expect it to jump to 160 MB by opening it because I can't see it making up memory out of nothing.

There is an edit history.  LabVIEW default is 99 actions.  (Tools >> Options >> Environment).  You can actually make that smaller.  I bet once the chart delete moves out of the Undo history, it shouldn't need to hold on to that memory for the chart data anymore.

The only way I know of for LabVIEW to save the history beyond a Save, Close LabVIEW Reopen is if you happened to have saved the data for that chart as default.

---

Thanks for testing, that pointed me to the solution: The memory allocation will be removed when the VI is recompiled.

If I understand correctly, opening in a new version forces a recompile, so the memory allocation did not show when opened in LV 2020.

I did not test reducing the edit history (saving, closing and reopening also flushes the history), but might give it a try if this becomes a problem again.

To add search engine hints: I noticed this problem when I received "Not enough memory to complete this operation" errors.