08-10-2018 07:36 AM
LV 2013, Win 7
In revisiting some old code (2003), I was making some convenience "wrappers" and measuring execution speed, compared to the old version.
I found a weirdness that I cannot explain - I'm wondering if anybody has any further insight.
Basically, I time a VI of mine doing a certain operation at 390 nSec +/- 2. I'm as careful as can be, I have a well-tested template for doing this.
The VI is subroutine priority, but cannot be inline, because it cannot be reentrant. Fine.
But when I measure the "wrapper" function, it actually measures significantly LESS time!
Namely, 301 nSec +/- 2.
The wrapper is inline subroutine.
So, why does it get faster? Is this real, or is the optimizer fooling me?
Here is the first test:
And here is the 2nd:
The wrapper code is here:
And the root code is here:
Attached is the timing template I developed and have used for 20+ years. It's free.
Why is a wrapper function faster, or is it?
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-10-2018 07:42 AM
For the record, the READ VALUES function does NOT benefit from the wrapper. The time is exactly the same, which is what I would expect.
Also note that all subVI front panels were CLOSED during the test.
Blog for (mostly LabVIEW) programmers: Tips And Tricks
08-10-2018 09:07 AM
What happens if it is NOT inlined?
Many years ago I did a very exotic application to test the speed difference using various transport media between PCs. I will spare you the log story but in the end I came up with a number that let me estimate how much time was required for each connector in a sub-VI icon connector. The more "spare" connectors the longer it took. Reduce the number of connectors, the faster it ran.
Since inlining is putting the code of the called sub-VI into the caller, the difference may be due to eliminating the overhead required to set and invoke the sub-VI.
A lot of speculating and hand waving I admit.
The DeskTop Execution Trace toolkit may give you some insight.
I f you learn the real answer, please let us know what you find.
Ben
08-10-2018 10:10 AM
You only attached the timing wrapper ("tester"), which is a bit Rube Goldberg for my taste. Can you also attach the "testee"
Is the image your subVI? I would probably use a feedback node instead of a dummy loop and shift register. Is this running on a PC or on a RT system?
08-10-2018 10:13 AM
@Ben wrote:
What happens if it is NOT inlined?
It is not.
QUOTE: "The VI is subroutine priority, but cannot be inline, because it cannot be reentrant."
08-10-2018 10:18 AM
@altenbach wrote:
@Ben wrote:
What happens if it is NOT inlined?
It is not.
QUOTE: "The VI is subroutine priority, but cannot be inline, because it cannot be reentrant."
Two lines later he wrote;
"The wrapper is inline subroutine."
Ben
08-10-2018 10:23 AM
@Ben wrote:
@altenbach"The wrapper is inline subroutine."
Obviously, we don't have all the facts. The wrapper has no connectors, so it cannot be used as a subVI and return data, meaning it is run as toplevel VI interactively. In that context, "inlined" has no meaning. 😄
08-10-2018 10:28 AM
Well, obviously all this lacks details. I guess the "Wrapper" is again something else. We need to see the entire code.
08-10-2018 10:34 AM - edited 08-10-2018 10:36 AM
@altenbach wrote:
Well, obviously all this lacks details. I guess the "Wrapper" is again something else. We need to see the entire code.
That would make it less challenging to answer.. yes.
But the images do suggest different icon connectors were used.
Edit:
And just for the record I have switched over too 100% feedback nodes instead of While loops with shift registers.
Ben
08-10-2018 10:39 AM
What happens if it is NOT inlined?
Interesting. I just did a reboot / reload and constructed the test again.
If the wrapper is inlined, I get 315 nSec
If the wrapper is non-reentrant, but subroutine, I get 323 nSec
If the wrapper is non-reentrant, normal, I get 365 nSec.
And now, if I call to the root VI without a wrapper, I get 305.
That seems reasonable.
This time it's with no project loaded.
Don't know what I did, but apparently it's a chimera.
So, sorry for the noise. We now return you to your regularly scheduled programming.
Blog for (mostly LabVIEW) programmers: Tips And Tricks