Releasing memory used by Charts and Graphs

[udka]

-To clear a graph programmatically, a Property Node or Invoke Node can be used.
-In Property Node method by assigning empty array and in Invoke node by reinitialize to default.
http://digital.ni.com/public.nsf/allkb/5B0B282E31E65E42862577A7005BC9AA
-Could you try both methods and see if results are same?
-Are there any other indicators(arrays etc.) ?
-Are how you sure that only the memory increase because of Graphs?
-Could you test it in development environment and profile the memory using and see if you see same change? : http://digital.ni.com/public.nsf/allkb/9515BF080191A32086256D670069AB68

[DiegoBallen]

Dear udka,

thank you very much for your feedback. Im sorry for the late response. We have lot of work lately in the company.

I followed your recommendations and I still get the same behavior. I prepared a simple VI to show the same behaviour I am having with my project (Test1.vi).

1. Check the memory usage of the running VI.

2. Press the button "Activate Data Generation".

3. Wait some time (I did it for 20 seconds) for data to be generated.

4. Press the "Stop Data Generation Button", which loads the data in the Graph controls,  and check the memory usage.

5. Press the "Clean Data" button to clean all graphs and check memory usage.

Please compare the memory usage obtained in step 1 with that one obtained in step 4. After executing step 5 I would expect to get a memory usage similar to the one obtained in step 1. Nevertheless the memory usage in step 5 turn outs to be significantly bigger that in step 1.

Is maybe this a default behavior of LabVIEW after working with considerable amounts of data?

Thanks for the help !!!

Regards,

Diego 

[RavensFan]

I did this and sometimes the memory was a bit higher after the last step.  Sometimes it was a bit lower.

It seemed to behave okay for me.

[altenbach]

---

@udka wrote:
-To clear a graph programmatically, a Property Node or Invoke Node can be used.

---

Why? Just coinditionally wire an empty array to the same terminal.

[natasftw]

---

@DiegoBallen wrote:
 

Initially the task manager reports 24.694 KB (24 MB).

and the task manager reports 404.640 KB (404 MB)

manager reports 170.076 KB (170 MB).

I finally get a reported size of 234.524 KB (234 MB).

---

We should take a look at this as well.  24KB is 24 KB, not 24 MB.  At no point in time will KB=MB.  404KB is 0.404MB.  170KB is 0.170MB.  If your concern is you're using 200MB, you shouldn't be.  You're using 0.2MB

In the first post, you mentioned a value property node for a graph.  Just feed the graph empty data with the wire.  There's no need to bring property nodes into this.

As mentioned elsewhere in the thread, It wouldn't be surprising if the chart maintains memory for the largest data set it has held.  Memory allocation is painful on performance.  For the small amount you're seeing, the performance hit if you refill the chart would be greater than the allocated memory being reserved.  You wouldn't want it to release that memory unless you were finished.  At which point, close the exe and it'll go away.

[perhult]

Come on people, there are different ways of writing decimal and thousand separators depending om country! The OP is using period as thousand separator.

https://en.wikipedia.org/wiki/Decimal_mark.

I suppose non-americans are more used to have this in mind when looking at numbers.

It is obvious from the context in the first post what the OP mean, and he has already clarified that he is talking about 24 - 404 MB.

As for the actual question, I too think it is expected that not all memory is redeemed. Memory allocation is complex. If you are anxious, why not test with larger datasets, larger that you expect to use in normal operation?

[Blokk]

The key point here is not the memory handling. The main thing is that you should NOT try to display more data points than the number of pixels of your monitor horizontally! If there are more data points than pixels on the graph, LV will decimate the data, and using huge data sets either using Charts or Graphs, you will end up with a sluggish GUI.

When you deal with huge data files, you should only display a portion of it or decimate the data. This will result in a faster application ( the built in graph decimator is not too efficient, better if you program this algorithm yourself).

[aputman]

---

@perhult wrote:

Come on people, there are different ways of writing decimal and thousand separators depending om country! The OP is using period as thousand separator.

https://en.wikipedia.org/wiki/Decimal_mark.

---

Maybe we should start a discussion about this decimal mark and why all the other countries are wrong.  Period is the decimal separator and comma is a thousands separator.  HAHA.  

[Blokk]

IMHO there is no need for thousand separator, since you can just create some space between the blocks. The comma decimal separator is superior over the period symbol. It is just obviously easier to read and more fail proof. We have this advantage in some countries in the EU over USA 😛

[altenbach]

---

@DiegoBallen wrote:

Sorry by my confusion, but I really meaned Graphs.

---

Again, there is nothing wrong. LabVIEW typically holds on to memory because it is very likely that the graph will use similar amounts of memory the next time it is called. Constantly deallocating then reallocating again would be significantly less efficient.

Testing in the development environment is also not reliable.