flat sequence structure for benchmarking

[Blokk]

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:

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?

[Sam_Sharp · Accepted solution]

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 

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.

[Blokk]

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

[Hooovahh]

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.