LabVIEW
0.5 MB program has 832 MB memory usage even before it is run
Oops 
I am not at all able to open the VI it shows "Generic error" and "Not enogh memory". My 2GB RAM is not sufficent 
Your various graph contains almost 200MB of default data in your array indicators alone!
3x 4000x2000 2D DBL arrays
2x 2000 1D DBL arrays
1x 2000 1D DBL array.
and I am sure there are other additional copies in memory (and we don't even know what's happening in the missing subVI).
In addition you also have value property nodes of same. That should easily explain the memory use. You should keep the huge 2D arrays e.g. in a shift register instead. I would also clear the indicators and make the new value the default before saving.
You are displaying 4000x2000 array data in an intensity graph with 400x200 pixels. You carry around 100x more data than can actually be shown.
Why is there no toplevel while loop? Are you using "continuous run" mode?
nbf wrote:1) If I understand correctly, what you are saying is that when I open the VI, the data structures associated with the intensity charts and waveform graphs are initialized to default values (e.g. 0), so there is memory usage even before the program is run and anything displayed, right?
Yes, a huge array still takes a lot of memory, even though it compresses well for storage inside the VI. Once the VI is ready to run, these arrays need to be allocated in memory.
nbf wrote:2) Is there an alternative to using the value property node that doesn't duplicate the memory content? (e.g. something like pointer or reference in C++?)
One possiblity are data value references. You can open a DVR and fill it inside the subVI, then extract slices later as needed. If done properly, you can also keep the 2D data in a shift register (yes, please learn about them!).
nbf wrote:4) Regarding the clearing of the indicators, could you please tell me how to do that, without removing the color ramp settings?
The color ramps can be set programmatically using property nodes based on array min&max and you can assign colors for the ramp values at will.
@nbf wrote:
5) You are correct that I am displaying 4000x2000 array data in an intensity graph with 400x200 pixels. But then I change the min/max of the charts/graphs to zoom into the region of interest; I can identify the region of interest only after displaying the full 4000x2000 array of data. I don't know if there is a way around this.
Do you really need to show the 2D data in three different transforms? Maybe one intensity graph is sufficient. You can apply the other transforms on the extracted slices with <<1% of the computing effort. What is the range and resolution of your data? Do you really need DBL or is a smaller representation sufficient (SGL, I16, etc). From looking at the subVI, the raw data is U16. The subVI also involves a coercion to DBL, requireing another data copy in memory. When running, make absolutely sure that the subVI front panel is closed, else additional memory is used for the huge array indicator there. For better performance, you might want to flatten the subVI to the main diagram or at least inline it.
@nbf wrote:
6) Yes, I use the continuous run mode instead of a toplevel while loop. Is there a disadvantage to doing that?
As Samuel Goldwyn ("A hospital is no place to be sick") might have said: "Run continuously is no way to run a VI" 😄
Run continuously is a debugging tool and has no place in typical use. What it basically does is restart the VI automatically whenever it completes, and as fast as the CPU allows. It is mostly useful to quickly test subVIs that don't have a toplevel loop and play with inputs to verify results. Any toplevel VI needs a while loop surrounding the core code. Period! 😄
So, my suggested plan of action would be:
- Use a while loop around your toplevel code
- Decide on the minimal representation needed to faithfully show the data.
- Keep a single copy of the 2D array in a DVR
- You optionally might want to undersample the data for display according to the pixel resolution and use other means of zooming and panning. For zooming, you could extract a differently sampled small array subset and adjust x0 and dx of the axes accordingly.
- Use a single 2D graph (if you need to see the various transforms, add a ring selector and transform the 2D array in place. Never show more than one intensity graph.
- ...
See how far you get. 😉
(He does not have arrays, just graphs: ---> right-click...data operations...clear graph.)
Here's a quick draft still retaining all your (potentially unecessary) graphs and functionality. Many things could be improved further, but this can give you hopefully some ideas. My advice from the earlier post still applies. (Many are not implemented in my example).
With all graphs loaded, it uses about 400MB in memory.
