calculating execution time

[RH2]

I have a related question that I think somewhat falls into the context of this thread: Is there any NI documentation on the execution times of all their built-in function blocks?

As illustrated in this previous VI, it takes a higher N-value to realize a delay given the speed. Though for developers utilizing the FPGA this could become something to deal with. I am programming a non-deterministic loop for the RT portion of a build and much of my information, though not at FPGA speeds, cycles a lot faster and gets written to the FPGA. I'm always interested in utilizing something more simple and efficient if it's available to me. Am I mistaken in being concerned about this? I've also been trying to avoid shared variable references as much as possible.

Richard

[Timmar]

I don't have a particularly good answer for your question, I too daily face which is the most efficient way to code labview.

My best advice is to think in assembler. What is the CPU going to have to do.

In my opinion there are 2 types of VI's,

1. Basic, efficient, Heavy lifting VI's

2. Easy VI's to make your block diagram neat. Tend to be multifunction and as a byproduct, inefficient

Each has their place in labview,

For applications that use lots of computation, memory manipulation or data searches I find it better to take control and work at an elemental level.

A good example is the "mean ptbyt" function

It is a fantastic module if you need all of the statistical data.

If not, there (may be) is many computations being performed that you don't need. I can't predict how LV will optimise the code.

If you just want to add up all the values and divide by the number, you would be better off using a for loop, or if you are the trusting sort, use the array sum function.

I added this example as a discussion topic. I would use the labview sum function because I don't see how LV could over complicate it.

I also use "In placeness", bitter experience has shown that if you don't actively control the memory, you may end up with many copies, consuming valuable cpu cycles and memory.

It is a double edged sword, as I found out recently, if you wire across an inplace structure, there is a tendancy to make copies. There is an inplace in-out element to compensate for this.

If you are not comfortable with inplace, use "replace array element" and bundle/unbundle.

Another neat trick i learned from reverse engineering the compress digital waveform vi is re-using memory.

An array into a vi can be used to store the outgoing data, Resize it as the last step before wiring it to the indicator.

As above, Don't be afraid to reverse engineer Labview VI's.

Their code in general is quite good, but may be ineffecient due to added functionality.

Strip out the good, efficient code tweak it to your high efficiency application.

Lookups and searches.

Index = good

1d string search = Bad

Sometimes a for loop with a conditianal terminal can be more efficient that a 1d lookup eg, multi variable lookup.

Hope that this helps

Tim L

[Chris V]

Hi RH2,

If you are very concerned with your performance in all of your applications, National Instruments does offer a LabVIEW Performance training class.

We do not publish any kind of document benchmarking all of our build-in functions.  That is largely dependent on system configuration and specific use.

Have a great day,

Chris V