05-23-2006 08:25 AM
The whole and single purpose of an inline function is to make the code execute as fast as possible without the need for actually calling a function, which is bound to take time.
With the scripting tools over at lavag.org it should be possible to make a preprocessor that does this in labview, and it shouldn't be that big a deal since it is a simple cut'n paste operation.
05-23-2006 09:25 AM
05-23-2006 09:37 AM
hi there,
if you would inline sub-VIs the code would inherit the priority of the calling VI. So the execution speed may be optimized, but only with the (maybe lower) execution priority of the calling VI whilst "real" sub-VIs keep their priority level. In RT apps (where you most probably would use this feature) this could lead to strange results.
05-23-2006 01:43 PM
I agree that an inline code functionality would not be a good choice for many cases, it may not have any effect at all, and could make things slow down in many cases as well as add other problems. But, in general when doing FPU extensive things, inline functionality is considered a MUST in other languages. My example earlier:
A(b,c) = b^2 + c^2
which is called as:
C = A(b,c)
When you look at this simple code, it makes no sense at all to add function call overhead to this. It is not neccesary from a compiler point of view or from readability point of view. For this simple code the overhead in labview would be some 50 ms per 100000 cals ( maybe 15 ms for subroutine flag on) while the floating point operations themselves only take 1-2 ms per 100000 calls. All this overhad will vanish when adding inline functionality while maintaining the readability and maintainability.