bsvingen

I have had the opposite experience. It is true that the total amount of overhead in absolute time for 1 mill calls is in the order of 100-500 ms. This therefore does not seem like a problem other than from an academic point of view. However, within such a sub vi you can put an incredible large amount of code doing floating point operation before the total amount of floating point time exceeds the time for one call to that sub vi. What seems like an academic problem is in fact a huge problem when doing floating point math. In fact it is practically impossible in most cases to make a numeric code doing math without loops that takes longer time to execute than it takes to call the code. Below is a snip from a post i did at NI site:

Hello. I did a test as you mentioned. One ordinary sub vi (all debugging etc turned off), one subroutine sub vi, one call by reference to that subroutine and just the diagram in the main program (debugging turned off in the main program). The sub vi was just adding numbers, and it was run i a loop 100000 times. The results in ms for 100000 calls:

Ordinary sub vi: 45

Subroutine sub vi: 11

call by ref: 125

diagram: 1

Then i complicated the sub vi with sine functions, division etc inside a loop that run 1000 times:

Ordinary sub vi: 1850

Subroutine sub vi: 1820 (30-40 less than ordinary sub vi)

call by ref: 1900-1950 (approx 80 more than ordinary sub vi)

diagram: 1850 (approx the same as ordinary sub vi)

All in all i guess this means that it is only the call itself that is affected by the subroutine option. But, the manual and help files say that sub vi call represent only a small overhead that is practically only for the smallest of sub vis. This cannot be true at all. The overhead even for a subroutine sub vi is huge when looking in terms of flop (floating point operation). These numbers show that a call to these different sub vis represent a certain amount of floating point operations:

Ordinary sub vi: 45 floating point operations (labview add, mult etc primitive)

Subroutine sub vi: 11 flop

call by ref: 125 flop

The numbers are actually larger than this since they also contain the overhead for the loop itself.

I also tried different trig, exp functions etc, and they are very efficient and do not cost considerably more than add, mult etc. Therefore, unless the sub vi contains a loop with some hundred iterations at least, making a diagram that cost less than the call to the sub vi itself is almost practically impossible, it will be too much spaghetti at once. 45 "flops" (in labview primitives) is a HUGE diagram and may contain several advanced math function. Other languages have inline functions because of this, and it is very strange that labview does not have this option considering the enormous overhead for sub vi calls in terms of flop.

For applications doing extensive floating point operations the overhead in making function calls makes no sense at all, simply because it is not neccesary. Getting rid of the function call overhead will speed up the application maybe 200 to several thousand percent depending on the amount of looping and the amount of function calls. C/C++ has this inline flag, while FORTRAN has inline subroutines and function by default, and this is not without reason. I have developed a fearly large simulation program in Labview, and i have compared the labview code using pure labview primitives (add, div, mult, subtract etc on vectors) with an optimized C routine. An optimized C routine is approx 150 % faster for pure floating point, but when trying to build sub vis to make the code more readable and easier to maintain, the added overhead makes it a waste of time, even when using the subroutine flag. The penalty is huge. It will be much easier, faster and more maintainable to make a DLL from C even though (presumably) there is som fair amount of overhead in calling that DLL from labview. The reason is mainly that C has this inline functionality. My point is that inline functionality is a very simple trick, but it does wonders for floating point math.

Hello

Would it be possible to write a small app that use scripting and preprocess a vi so that sub vis are inlined like in other programing languages. When execution speed is important as well as readability of the code, then inline functions is essential. Unfortunately function calling in labview is very slow and there is no option to inline the code, thus to make it fast, the code becomes unreadable.

But with scripting i guess it will be possible to use inline functionality as a sort of preprocessor option to just copy and paste the diagram of the sub vi into the main program ??

The subroutines could be reckognised for instance with an _inline_ in their names.

Would this be possible? It would be extremely usefull for apps that need to run fast.

BSvingen