LabVIEW
Selecting "inline subVI" seems to be disabling constant folding
I'm running this VI 100,000 times in a for loop. With "preallocated" on and "allow debug" off, it takes about 165 ms. As soon as I select "inline", it jumps up to ~4,000 ms. My guess is that it's disabling contant folding (which would cause more processing time in the for loop). I thought inlining was supposed to make things faster 😉
Here's the caller if it helps. Everything is normal (Debug on, non-reentrant, no inline)
Can you attach the actual VIs instead of snippets? Thanks.
(snippets don't show VI settings and such).
Jeff·Þ·Bohrer wrote:Your caller inputs to the inline me vi are not constant! how could the inlined vi be folded?
You can not fold a routine that gets a random array! What if "Fold me" was replaced by sort array? (that is a really poor sort )
No, but the FOR loop inside of the inlined VI should be folded since it gets a constant array as an input. That is what is adding all of the time.
Once the subVI is inlined, only the debug setting of the caller should matter. However after disabling debugging of the caller, we still don't get any folding advantage. This is not right.
In the subVI, everything except "index array" should get folded. The FOR loop only depends on diagram constants and thus can be computed at compile time and replaced by a single new diagram constant. In fact it is, as seen by the structure folding display:
The inline setting should be irrelevant, but it is apparently not. Somehow it forces the loop to be computed over and over with every call. (guessing from the long time it takes. Wht else could be slowng it down?!)
Something is definatly not right.
Just because I suspected something odd with the clone pool checkout (which turned out to be moot since the sub-vi is inlined)
Then I configured loop parallism
x-y became 0
but the vi still executed about as fast as expected (@2x speed)
That can't be right 0 ms!!!???????
Lets swap to a different timer
MICROSECONDS! in x-y Yet the vi still took about 2.xx seconds to execute
Maybe the random gen loop took some time: Nope about 7mSec
Somebody did something !
OK lets double down on the data flow.
Spooky. Eerie
yup I'll go find a hole to hide in
@crossrulz wrote:
@JÞB wrote:
Something is definatly not right.
Did you notice that your parallel FOR loop finished IN THE PAST!!! Yeah, I'd say something got screwed up there.
YUP. That's when I went and hid.
Then before Dr. K could arrive and make me look foolish
