> Sounds like you are passing a 100MB array to your sub-vi. As soon as > you do this, you make a copy of the data. That is, the input variable > is not a reference to the array, it is a copy of the array. To > understand this more clearly, think about wiring the same array to > four or five different sub-vis, each doing something different with > the data. In order to have each of the sub-vis work with the original > array data, each one must make a copy of the array. > > You can limit the number of copies of the array by using global > variable (Shh, don't tell anyone that I suggested it.). You can also > use control references, i.e. if the value is in a control in the > calling vi, you can pass a reference to the control to the sub-vi and > get the array values from a property node. Also, you can create your > own memory chunk using the "extcode" library memory management > functions and a CIN or a DLL. NI suggests using a "functional global" > for this purpose. They are usually right. After all they wrote the > stuff. > > Check out this link to the NI site: > http://zone.ni.com/devzone/conceptd.nsf/webmain/6A56C174EABA7BBD86256E58005D9712?opendocument
I'm afraid that I'll have to disagree with most of these recommendations. LV arrays and other types do work by value, so splitting an array must behave as though each recipient gets its own copy, but that doesn't mean that the LV compiler can't optimize some of them away, and that is in fact what it tries to do. What you are most likely seeing is that your subVI is left open or is otherwise unsaved. This means that LV updates the values in the subVI for debugging or display to the user when the panel is opened. If your subVI has an array in, an array out, and uses replace array subset, you should get it to work on the original array in. Beware that if your subVI is a little off or if your top VI displays the array, copies can be made. So how about globals? Globals make copies too. In fact writing a 100MB array to the global means you have two of them. You can then shrink the callers, but you have to do it explicitly. Then when you read the global, you get another 100MB. If you make a functional - LV2 style - global, you can read back or access just what you need, so they are better, but not better than wires. How about control references? Please don't treat them like data pointers. They are references to a complex UI element, not data. Most of the same rules apply as wth the global, but since they are display objects, you are going to get yet another copy used for UI. As for the referenced article, this was written by someone who has dealt with very large arrays on a regular basis. I'd highly recommend you read it, then you can use the techniques when they are needed and when the additional complexity and tradeoffs are called for. Greg McKaskle
