Performance problem with graphs on Tabs (LV7.1)

[F._Schubert]

I have huge performance problems in a subsystem using tab controls with graphs on top. The whole thing worked nice, until I record a measurement (abou 10k of double as data displayed on the graph). The win task manager indicates above 50% on both CPUs, the app hangs (or lags), my queues generate timeout messages...
The graph is located in one of the pages of a tab control. As well are several clusters of config data for the measurement.

As I said, the problems started, when I put the data of that size on the graph indicator.

The clusters are some nested typ defs, but it worked with them before, no huge arrays involved. All are bundled in a huge cluster (less than 1 k if saved as xml).

So I wonder, if the clusters and/or the graphs are the problem PLUS is that problem resolved in current LV-Versions (hoping to get the faster car & and I love the current GUI with tabs)?

Sorry, can't post the code, but if none of you knows that kind of problems and I can't solve it on my on in an hour or so, I can make some imitation code.

Felix

[BillMe]

How many graphs are you referring to?
Are they all on your User Interface and running in the UI thread?

You might want to try putting your graphs in their own threads i.e., called dynamically or otherwise in a structure that allows LabVIEW to put them in their own thread. I've gotten good performance out of a PXI-8106 controller by calling a graph template dynamically. That's four graphs showing at once, 12 plots per graph, 10000 XY value pairs per plot. Each graph was setup to get its data every 50-200ms.

How much data you can plot with decent performance also depends on the hardware you're using, i.e., CPU speed, RAM size, video capability, etc. It can also depend on how efficiently you've coded your application. Are you initializing your data arrays and using "Replace Subset" or are you using the less efficient "Build Array" for example?

Message Edited by Bill@NGC on 09-11-2007 09:31 PM

[parthabe]

---

@f. Schubert wrote:
Sorry, can't post the code, but if none of you knows that kind of problems and I can't solve it on my on in an hour or so, I can make some imitation code.

Felix

---

I think you can post some imitation code NOW...

[F._Schubert]

Here is a sample code.
If you profile CPU usage with the task manager, you will see that switching the tabs consumes more than the 'measurement' alone. Consider, that I have several tabs with nested clusters as configuration parameters.

[parthabe]

Eventhough we think that we re only switching the Tabs, LabVIEW has to redraw all the point [1000000x1000000] point on the graph lying inside the Tab, each n every time we switch the Tabs. So, that consumes a whopping CPU resource.

This could be the reason behind this problem.

I tried putting a Timeout event of 10ms so that LV does not get locked inside the same event of Measure1 or Measure2, but still the same result.

Somebody with large no. of graphs project experience should help you achive what you want.

[GerdW]

Hi F. Schube...,

why do you want to plot 10k+ (in your example 1M) of data values in a only 300 pixels wide graph?
This doesn't make sense as each pixel of the graph will represent many data points...

Hints:
- each indicator has it's own datacopy: so you need a 8MB data copy for your 1M data points (DBL representation!)
- try to decimate your data arrays (only) for display

[parthabe]

Probably you should see the below link...

http://zone.ni.com/devzone/cda/tut/p/id/3625

[F._Schubert]

Thanx to you all, though I knew the tricks, you just pointed me to the obvious: I don't need that amount of data at all.

What still irritates me, is the point that I can deal with that amount of data at another part of my app. I checked the memory usage via task manager, and it increases in the app by 50 MBs in the case I described, at the other part it increases about 100 MBs without disturbing the background processes. I got the data I did need once, I don't need it for normal operation.

5 stars to you all,

Felix