Allow the creation of "Inplace"-VIs

[Marc Blumentritt]

I give an example to explain what I mean:

1.) Create a big array, eg 200x 200 x 200 3D-Array.

2.) Create a sub-VI with a 3D-Array input and output. Inside the VI, use the replace element function to replace one elemente of your choice.

3.) Connect the big array with your sub-VI and check the timing.

With LV8.5 I get about 200 ms for running the sub-VI. Checking the replace element function gets delta t of 0 ms! It looks like, that the output of the sub-VI has to allocate new memory for the array, even if I do not change the size of the array.

It would be cool, if I could create sub-VIs, which reuse pre-allocated memory for the inputs and outputs, therefore allowing a similiar effect as the inplace structure. As of how to configure this in LabVIEW you can be creative 😉 Perhaps do this with the conector pane.

Regards,

Marc

[AristosQueue (NI)]

Please post the VI you used to test this so I can be sure exactly which problem you're referring to before I comment further.

[altenbach]

0ms (vs. slow) on very large data structures typically indicates constant folding. I agree that you need to show your VIs and test setup. How many times did you run it?

Make sure you display constant folding and buffer allocations to get a better idea what's happening.

[JackDunaway]

Regardless of whether Marc correctly benchmarked, I agree and would like to see an "Inline" execution priority, as originally proposed by Mads.

To ensure you did not constant fold, hook up a control to one or more of the Initialize Array inputs, and set its value to 200.

One more thing... could you run a benchmark passing a data reference into the subVI? I have not yet done any benchmarking passing by reference rather than by value in LabVIEW 2009. This seems like a viable solution to slow execution due to unnecessary buffer allocation.

Message Edited by mechelecengr on 08-18-2009 12:33 PM

[Marc Blumentritt]

For reasons unknown I cannot upload images to the forum at my work (certainly some firewall problem!?). I will try to upload my screenshots from home.

[Intaris]

Did you have the FP of the sub-vi open when testing?

I just reproduced this and say that with the FP open, the data copying for the CONTROLS on the FP create a delay with the Sub-VI but if you close the FP I get 0ms for each version.

Sub-Vi Hidden :  Replace Primitive = 0ms, Sub-VI = 0ms

Sub-VI Shown : Replace Primitive = 0ms, Sub-Vi = 43ms

Visible Controls duplicate memory space.  Close any unnecessary FPs and LV should in-line for you.

[Marc Blumentritt]

Yes, I realized this, too, when I rechecked my numbers. I forgot to close the FP and got 200ms. But with closed FP I still get around 60 ms for the sub-VI running. I did a finer check of my timing by getting a timer millisecond value after each step. The 60 ms result on my PC with "stepping" into the Sub-VI (I will later upload the images). I think this is the sub-VI overhead described in Mads idea. Perhaps the automatic background "inlining" described there is the best solution for this problem?

[Intaris]

I still can't reproduce your timing anomalies.  A single VI call should not create more overhead that a few microseconds.  Painful for a routine called millions of times to do simple tasks, but certainly not timeable with a 1ms resolution.  Anything else is data copying.  Please post the VI.

[altenbach]

I would probably recommend to take this discussion over to the LabVIEW board. The Idea area is not very suitable for detailed technical discussions.

[Marc Blumentritt]

OK, moved to the LabVIEW Board. Please come back, if you want to give kudos 😉

[Darren]

Any idea that has received less than 4 kudos within 4 years after posting will be automatically declined.