Why is subvi slow

[MaartenM]

I have an application that uses Variant data to store and data. There are several layers to my data structure.

If I try to retrieve data using in-line code I can find the correct data 10,000 times faster than when I use the exact same code in a subvi. Why s there such a large speed difference.

I prefer to use subvi's because I will be re-using the code in many places throughout my main application. Any suggestion how I can improve the performance of this function are appreciated.

Attached is a simplified example that show the speed difference. (LabVIEW 2009)

Many thanks,

Maarten

[johnsold]

Maarten,

The code is probably not that much faster but the measurement technique makes it look that way.  Look closely at the diagram.  The code in the second (none subVI case) is all constant folded.  The compiler determined that nothing could ever change in that code so it precalculates it and hands it to the output.  Putting controls in both for loops forces the compiler to run all the code.  Of course the controls have to be read on each iteration.  When I do that the subVI takes about 8.4 ms and the other about 1.1 ms, a 7x factor rather than 10000x.

Lynn

[Darin.K]

When I take it one step further and create an array of variants and feed this into each For Loop I get nearly identical times for the two methods.  The SubVI can be sped up (very) slightly by changing the execution priority to subroutine.  You had already disabled debugging, good.  Benchmarking is always tricky.

I write a lot of demanding VIs and will inline as much code as anyone around.  Even I will tell you that a SubVI for an operation such as this is a good choice. 

My two cents:

Look at your benchmarking code.  The SubVI in a tight loop is often a suboptimal solution.  I know it is appropriate here since this is for timing purposes, but it is an example of a construct I look for when trying to squeeze a few flops out of an operation.  I seem to think that LV10 or soon thereafter may have some interesting options to have the look of a subVI with the performance of inlining.

Other than that case, it is hard to argue against subVIs.  Unless you are truly glutton for punishment and carpal tunnel syndrome, you will never place enough subVIs on a diagram to suffer a significant hit in overhead.

[Yamaeda]

My first run gave 14900 ms vs 0,0001ms!

Somehow the sub vi wasn't subroutine for me, so with that change it quickly changed to 0,91 vs 0,0001

Inlining should ofc make it equal.

As an extra test i made a 3rd subvi which included the loop and got 0,0008ms.

/Y

[Yamaeda]

As mentioned, feeding the loops arrays instead makes all 3 alot more equal.