LabVIEW
Why is the Space Constant so slow?
Obviously I'm asking comparatively since they are faster then the blink of an eye.
When trying to optimize some of my functions I've noticed that this one constant is really slow.
Here's my test VI: I simply am measuring the time it takes to append a character to a string. If the string doesn't exist, don't add anything. This also prevents the compiler from optimizing out the for loop.
Most cases I've averaged about 250 ms. However, if I used the space constant instead of putting a space character in a string constant. It nearly 10-fold the time it takes to nearly 2.1 seconds.
So I question why is this the case? I don't see why all the other constants (I checked) run at full speed, but the space constant (which I can see it's block diagram) takes significantly longer. Is this a bug?
If you double-click the space constant, you'll notice that it is actually a VI, so there is more overhead.
Also note that your VI is somewhat flawed. Once you disable debugging, everything runs at 0ms, because the inner code is folded.
I know it's a subVI, that's what I am questioning in this topic. Why of all the string constants is that one a subVI when all the rest are not? All the rest appear to be a raw function. (Which I'll assume is even faster then inlining)
As for being flawed. I wanted it to be. I don't want my for loop to be folded away. This simple test VI is so simple that it takes literally 10 million runs to have reasonible run time for compairison. If you fold it away to a single run, you can't see the effects.
bsvare wrote:As for being flawed. I wanted it to be. I don't want my for loop to be folded away. This simple test VI is so simple that it takes literally 10 million runs to have reasonible run time for compairison. If you fold it away to a single run, you can't see the effects.
Well, it is flawed in the wrong way, because most likely the presence of a subVI will cause more complicated debugging code and the effect might be secondary. You could e.g. eliminate folding by e.g. doing a comparison of "[i] != 0" or "[i] AND 1" for the case decision. Now all variantions seem to be about the same speed (with or without debugging, resp., where debugging poses a large penalty).
