LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Execution Speed Anomaly

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:

Obj Timing.PNG

 

And here is the 2nd:

Obj Timing 2.PNG

 

The wrapper code is here:

Obj Timing 3.PNG

 

And the root code is here:

Obj Timing 4.PNG

 

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?

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 1 of 15
(3,683 Views)

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.

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 2 of 15
(3,681 Views)

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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 3 of 15
(3,655 Views)

You only attached the timing wrapper ("tester"), which is a bit Rube Goldberg for my taste. Can you also attach the "testee"

 

  • So you are using a millisecond ticker to measure nanoseconds. Why not use "high resolution relative seconds"?
  • What exactly determines the execution speed?
  • I probably would not use subroutine priority.

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?

0 Kudos
Message 4 of 15
(3,642 Views)

@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."

0 Kudos
Message 5 of 15
(3,639 Views)

@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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 15
(3,636 Views)

@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. 😄

0 Kudos
Message 7 of 15
(3,633 Views)

Well, obviously all this lacks details. I guess the "Wrapper" is again something else. We need to see the entire code.

0 Kudos
Message 8 of 15
(3,630 Views)

@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

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 9 of 15
(3,624 Views)

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.

 

 

 

Steve Bird
Culverson Software - Elegant software that is a pleasure to use.
Culverson.com


Blog for (mostly LabVIEW) programmers: Tips And Tricks

0 Kudos
Message 10 of 15
(3,619 Views)