calculation performance in large sized graphs

[labmaster]

Memory problem occurred in several graphs with 20,000 x-y data on front panel in stand-alone execution program as well as LabVIEW environment.

When I checked, the memory problem disappeared because I didn't display the graph represented by a lot of points.

Usually, only arrays of data are considered memory resources.

I'm not sure why you're allocating so much memory in displaying data in xy graph indicator, but how can you pre-evaluate the memory resources of an xy graph when designing a program?

Or is there an indicator to check the resource occupancy in the development environment?

labmaster.

[LVNinja]

if you go to VI properties, (right click on top of the icon of the front pannel)

 then go to Categories - MEMORY USAGE it show the amount of memory your vi is using. 

You can try running a couple of times to see the difference. 

[altenbach]

20000 x-y data points is not much!  Are you sure you are really running out of memory. What kind of error do you get?

One problem with pushing so much data to a graph indicator is that you are taxing the UI thread, making the program sluggish in general. Make sure to also simplify the graph (single-width lines, no fancy point styles, no anti-aliasing, etc.) and avoid overlapping controls. Maybe decimate the data for display because it is unlikely that you have a graph that is 20000 pixels wide.

How are you building the graph data? Are you constantly growing array or are the data sizes fixed and in-place? Are you using the "build xy graph" express VI set to not clear data between calls? What is the datatype of the graph (array of xy points? cluster of X and Y arrays? Complex 1D array?)? Can you show us some simplified code?

[labmaster]

thanks for the response
My original question was not correct.

When I say memory resource, I mean cpu performance.

Displaying several graphs of many points (with a large area) on the Front Panel dramatically reduces system resources and slows down calculations.
This was confirmed by the increase in the number of data waiting in the queue over time.

In this case, if you change the graphic (graph) of the front panel to invisible, the calculation speed of the system increases. That is, the number in the queue decreases rapidly.

What is clear from old memories and current work seems to be related to the spatial size of the graphic on the front panel.

However, I can't really think of a way to know or evaluate this in advance. Is there any way to anticipate in advance?

labmaster.

[altenbach]

Simply don't push more data to the UI than the user can comfortably process.

The UI is (necessarily) handled by a single thread that asynchronously takes the data from the transfer buffers of front panel objects and renders them to the front panel. Copying huge amounts of data and translating it all into a fancy front panel "image" is very expensive. For an XY graph, it not only needs to map all the data to pixels, it also needs to draw the lines, points and other decorations, Note that blatant overuse of property nodes can make the problem ever worse, because most must also execute synchronously in the UI thread. Once the UI thread saturates one CPU core, everything else suffers.

We can probably give more specific advice once we have more details. Can you answer my earlier questions? How often do you update the graph? What's the loop rate?

[Yamaeda]

It sounds like you're doing everything in one loop. If so, then yes, drawing graphs will impact your overall performance.