LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

flat sequence structure for benchmarking

Solved!
Go to solution

Hello,

 

Maybe this is very obvious, but I do not fully understand something with flat sequence structures-FSS (I never use this structure by the way, and I do not get why they use it in this example).

There is a NI doc online explaining some rookie mistakes in LV:

http://www.ni.com/newsletter/51735/en/

The doc describes that the FSS is useful for benchmarking, the BD:

amndactq6630960983613965242.png

 

My question: what about if we put the Tick Count in a subVI at the left and at the right, and giving the exec. order with error wires? Or using a while loop which executes only once (with error wires passing through)?

Are these 3 different ways identical?

0 Kudos
Message 1 of 4
(3,883 Views)
Solution
Accepted by Blokk

Yes you can do all of those things - I think the only thing to bear in mind is that you don't want your benchmarking code to affect the execution speed of the code - otherwise you'll get inaccurate results. If you use the while loop, you'll need to do something to ensure that your second Tick Count executes after your While loop - e.g. with an FSS Smiley Very Happy

 

Using the flat sequence structure is OK - it's overuse of it that is a common rookie mistake - trying to force things to execute in a specific order (e.g. if coming from a text based sequential programming language) instead of understanding that this is done by data flow in LabVIEW.

 

I think the reason for it is just because the Tick Count VI doesn't have an input so you can't enforce data flow. It's quite common to have a subVI that wraps the tick count VI with error in/out wires.


LabVIEW Champion, CLA, CLED, CTD
(blog)
Message 2 of 4
(3,871 Views)

Thanks! It is more clear now. So a while loop actually changes the things too much, so it is not good here. A subVI needs to be created, so I see why it is just quicker to drop a FSS instead...

0 Kudos
Message 3 of 4
(3,855 Views)

Actually depending on the precision you want, that example has other issues.  Altenbach has a post somewhere that I can't find at the moment that lists out how to best measure the speed of some code.  Here are some of the points I remember:

 

  • Turn debugging off in the VI, and turn automatic error handling.
  • Inline any subVIs to help speed if possible
  • Get a tick count when nothing else is going on, meaning not in parallel with any other code
  • Perform the code to be measured, but do not update any front panel indicators.  This update happens asynchronously and may make incorrect results
  • When inputs are needed, use randomly generated data when possible.  The compiler is smart and may try to optimize away results it has seen recently.
  • Get a tick count after the code is done when nothing else is going, meaning not in parallel with any other code.
  • After getting the tick count a second time, indicators can be updated
  • Subtract the time difference between the two ticks.

Without following these steps you'll still get a pretty good idea about how long something takes to do, but when comparing multiple coding techniques for speed, these steps help make a level playing field.

Message 4 of 4
(3,792 Views)