How are LabVIEW functions are Faster than Custom sub VI 's

[F._Schubert]

For benchmarking, you also should somehow exclude the Control and Indicator (Image in, Histogram). Both will result in at least two additional data copies each.

Of course the same needs to be done for the IMAQ version. 

For such benchmarking, using flat sequences is ok. Get the time in the 1st and 3rd frame, place the code inside the second frame. Run the wires from/to the control/indicator inside the first/out of the third frame! 

Felix 

[lordsathish]

Hi Ppl,

I tried dividing the array in to two and run the computation parallel y.   I found that it was actually worse than the previous code. I also tried using the dll approach. I discovered that when we create a exe out this code it gives the same performance as the dll.

Thanks, 

[F._Schubert]

Also some more performance boost: Set the Execution priority to subroutine.

Felix 

[Coq_Rouge]

Labview is well know for being a memory guzzler. As an example very few Labview signal processing VIs do have a core written in Labview. Because they would be to slow.  

[Ben]

If you chase down the links in the tag for LabVIEW_Performance you will find discusion of the many factors tht can affect LV performance.

I have seen and read of people getting performance that rivals the built-in functions and in an old version of LV even beats the built-in but it is rare.

If you read through all of those linked messages and spend some time benchmarking you should get good performance, but do NOT expect to beat what NI supplied but my if any.

In the above eaxmple there are two issues (at least).

1) The memory manager is invoked everytime to allocate the array for the histogram. If the caller created the buffer and passed it in (see the Clear as mud thread), that would improve performance.

2) Similarly with the data coming in.

So review those linked threads and do some benchmarking.

If you find something interesting or suprising post images and benchmark results and let us hob-nob on what you find.

Ben

[altenbach]

• If this is a subVI, make sure it's panel is closed when benchmarking. If you have it open (and it's not set to subVI as suggested elsewhere), it will need to update the control of the huge 2D array, which might be expensive.
• Disable debugging.
• How are you benchmarking the performance? Maybe your method is flawed. 😉
• The I32 conversion does not add anything useful. Leaving the coercion dot might actually be slightly faster.

Please attach your actual histogram VI and benchmarking setup. How big is the 2D array.

---

Ben wrote:

1) The memory manager is invoked everytime to allocate the array for the histogram. If the caller created the buffer and passed it in (see the Clear as mud thread), that would improve performance.

---

I disagree here. The histogram array is constant and folded at compile time.

(It's also tiny and probably would not be releveant, even if it were allocated every time.)

[Ben]

---

altenbach wrote:

• ...

I disagree here. The histogram array is constant and folded at compile time.

(It's also tiny and probably would not be releveant, even if it were allocated every time.)

---

Yes but that buffer can not be used at run time since the next call of the sub-VI would find the results from the previous run. It SEEMS the constant folded buffer has to be copied to a working buffer in the SR.

Just speculating and appreciating your feed-back and in-sight,

Ben