Graphics-related slowdown "permanence" until LV is closed completely - why??

[bodypillow]

Hi All,

I am having a weird problem with a VI I use to view data.  I've attached the VI for reference and a few screenshots of it being used with data, but unfortunately I cannot upload the data itself.  This means you will not be able to try to replicate the problem, but I have verified it on two separate (and very different) windows machines so I don't think it is related to my PC or particular LV installation. (LV2017.0f2 in both cases).

The VI reads data from N files and plots a bunch of different metrics computed from the data.  The front page has 5 tabs as described below:

1) XY Main View: lots of datapoints graphed per file

2) Linearity:          lots of datapoints graphed per file

3) Time Domain:  lots of datapoints graphed per file

4) Rbr Comp:       only 1 datapoint  graphed per file

5) Statistics:         only 1 datapoint  graphed per file

When reading in a small number of files (~10), the front panel is quite responsive when switching between tabs.  I have an event structure used to trigger a re-draw of the graphs on the tab being switched to (which has been necessary for the data to display correctly, no big deal).

When reading a large number of files (~100), the front panel is quite laggy when switching among tabs 1-3 (the ones with lots of datapoints per file on their graphs).   Fair enough; I am asking a lot of the drawing engine.  This doesn't bother me much.  Switching among tabs 4-5 is still speedy.

However, the problem that is bugging me greatly is that: if you stop the VI after reading a large number of files, and run it again to view a small number of files, the lagginess that was originally only present for the large number of files remains!  Again it is only among tabs 1-3, but still!  All of the graph objects are cleared both at the end of running (if stopped by my stop button) and at VI initialization before files are selected.

The only way that I have found to get the front panel to become as responsive as it should be with the small number of files is to close the instance of LabView on the machine completely.  I have tried just closing the VI, closing the project completely (leaving only the LV initialization/splash screen), and neither are enough.  LV must be completely completely closed.

I have no idea how to approach fixing this problem.  Any advice is appreciated.

[Blokk]

I am on a phone now, so cannot see your VIs.

You mention "lots of files". Actually this is irrelevant. The question is how many data points? Do you try to plot more data points then the horizontal pixel size of your graphs? If so, you should consider decimating (average, median, etc. pick what best suits you) your data before plotting it. LabVIEW does this automatically, but you can speed up things if you do it own your own. I always use an algorithm in my code which checks the pixel size of my graph and decimates the data to fit properly. It does not make sense to plot more points than pixels you have... does it? 🙂

Some more thoughts:

1. Any application you make should turn finally into an EXE. You do not need to run the full LabVIEW IDE, you only need the LabVIEW runtime engine (RTE), and maybe some other things depending on your used drivers (DAQmx RTE, VISA RTE, etc...).

2. You should consider leaving TABs. TAB containers do not play nice together with lots of graphs. If you want to be more pro, start to use subPanels. Fast, scalable, efficient.

[GerdW]

Hi body,

When reading a large number of files (~100), the front panel is quite laggy when switching among tabs 1-3 (the ones with lots of datapoints per file on their graphs). Fair enough; I am asking a lot of the drawing engine.  This doesn't bother me much.  Switching among tabs 4-5 is still speedy.

You put graphs into clusters into tab pages: this is probably not the best data structure. Putting graphs into clusters has been reported to give unexpected problems. Putting lots of graphs into several tab pages needs lots of memory. Plotting large amount of data needs lot of memory. Ehm: is your VI laggy sometimes?

On your VI:

- use more shift registers to hold your data instead of all those local variables (or "value" property nodes)!

- why are there unwired terminals in the "0.00" state? Use them in other states!

- use unique labels for FP elements! You still can show different captions to the user…

Suggestion:

- hold data in shift registers

- update graphs only when needed

- stay away from "value" property nodes

- don't stuff your graphs into clusters! (You still can collect data in clusters in your shift registers, but creating clusters for the GUI including graphs is not recommended…)

- learn about subpanel usage…

[bodypillow]

---

@Blokk wrote:

I am on a phone now, so cannot see your VIs.

You mention "lots of files". Actually this is irrelevant. The question is how many data points?

That's why I mentioned which tabs have graphs with many datapoints per file.  datapoints on those graphs = datapoints per file * # of files

Do you try to plot more data points then the horizontal pixel size of your graphs?

Potentially yes, I haven't checked this explicitly

If so, you should consider decimating (average, median, etc. pick what best suits you) your data before plotting it. LabVIEW does this automatically, but you can speed up things if you do it own your own. I always use an algorithm in my code which checks the pixel size of my graph and decimates the data to fit properly. It does not make sense to plot more points than pixels you have... does it? 🙂

Definitely not.  Of course decimating the data before plotting is a logical response to the slowness of the VI when viewing the large number of files.  However, as I mentioned above, I understand why this slowdown exists while viewing the large data set.  What I don't understand is the permanence of the sluggishness after that data is (as far as I can tell) completely cleared both from view and from memory, and a smaller dataset is re-analyzed, now with much worse responsiveness than before.  It is this puzzling behavior that I'm seeking help for, although the other tips are appreciated.

Some more thoughts:

1. Any application you make should turn finally into an EXE. You do not need to run the full LabVIEW IDE, you only need the LabVIEW runtime engine (RTE), and maybe some other things depending on your used drivers (DAQmx RTE, VISA RTE, etc...).

I don't have the license to be able to to do this, but nonetheless, if I were to get it, what effects would it have on the behavior described?

2. You should consider leaving TABs. TAB containers do not play nice together with lots of graphs. If you want to be more pro, start to use subPanels. Fast, scalable, efficient.

Good to know.  Thanks.

---

[GerdW]

Hi pillow,

What I don't understand is the permanence of the sluggishness after that data is (as far as I can tell) completely cleared both from view and from memory, and a smaller dataset is re-analyzed, now with much worse responsiveness than before.

LabVIEW handles memory using its own handler. And somehow it might think you will need the large memory buffers again, even though you loaded smaller files in the meantime. And there are several buffers: in your shift register, in those several controls, the property nodes might require an additional buffer, and last but not least all those graphs get their own copy of the data!

[bodypillow]

---

@GerdW wrote:

Hi body,

When reading a large number of files (~100), the front panel is quite laggy when switching among tabs 1-3 (the ones with lots of datapoints per file on their graphs). Fair enough; I am asking a lot of the drawing engine.  This doesn't bother me much.  Switching among tabs 4-5 is still speedy.

You put graphs into clusters into tab pages: this is probably not the best data structure. Putting graphs into clusters has been reported to give unexpected problems.

I definitely didn't know this.  Are there any resources (NI or user based) which explain what the nature of these unexpected problems are and when specifically they might occur?

Putting lots of graphs into several tab pages needs lots of memory. Plotting large amount of data needs lot of memory.

Of course

Ehm: is your VI laggy sometimes?

Again, only during (understandable) and after (less understandable) viewing large datasets.  It is mainly the after behavior I am trying to zero in on and understand, because it doesn't make much sense to me.

On your VI:

- use more shift registers to hold your data instead of all those local variables (or "value" property nodes)!

Fair enough.  I usually have a part of my main data cluster which is dedicated to controls.  I don't know why I didn't do it here.

- why are there unwired terminals in the "0.00" state? Use them in other states!

Just organization habit I guess.

- use unique labels for FP elements! You still can show different captions to the user…

 I didn't realize I didn't do this already.

Suggestion:

- hold data in shift registers

- update graphs only when needed

- stay away from "value" property nodes

- don't stuff your graphs into clusters! (You still can collect data in clusters in your shift registers, but creating clusters for the GUI including graphs is not recommended…)

- learn about subpanel usage…

---

Do you have any recommendations / insight on my main question above?

[bodypillow]

---

@GerdW wrote:

Hi pillow,

What I don't understand is the permanence of the sluggishness after that data is (as far as I can tell) completely cleared both from view and from memory, and a smaller dataset is re-analyzed, now with much worse responsiveness than before.

LabVIEW handles memory using its own handler. And somehow it might think you will need the large memory buffers again, even though you loaded smaller files in the meantime. And there are several buffers: in your shift register, in those several controls, the property nodes might require an additional buffer, and last but not least all those graphs get their own copy of the data!

---

Does the user have any control over this behavior?  Is there anything I can do at the VI level to prevent this behavior?  This is mainly what I'm interested in.  Not to say that I can't or shouldn't reduce how much I'm using in the first place.

Furthermore, I don't quite understand why, even if LabView does keep this memory, why it would make subsequent processing so slow.  It is only using at most ~1-2GB on a 16GB ram machine.  In my mind, there should always be a trade-off between memory allocation and speed (space-time tradeoff), provided you don't use so much memory that the normal execution processes don't have as much as they need to do their job.

[GerdW]

Hi pillow,

Does the user have any control over this behavior? 

Not directly…

As you heard by now you should decimate your data copies to reasonable amounts. No need to plot millions of points in a graph of ~500pixels width.

And there is a RequestDeallocation: be careful when placing it in your code. It will not free memory instantly nor improve the execution speed…

It is only using at most ~1-2GB

Which is quite a lot. At 2GB you can already handle 256M DBL values, or 1G U16 values…

Most time (in my experience) is taken when you force LabVIEW to draw graphs on the GUI with lots of data in the plots. As soon as you cut the amount of data you will notice more better responsiveness when switch your tabs.