LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Compare performance of vis

Solved!
Go to solution

Hi,

I am trying to determine which of these vis need least time. Which needs the least memory. I tried to compare them using Profile performance and Memory tool. But I get 

exactly the same time of execution. Please advice what would be the best way of doing this.

Thank you.

Download All
0 Kudos
Message 1 of 9
(4,570 Views)

They should all take near zero time.

 

I think that all three examples you showed are being folded since the answers are always the same. The answer is computed at compile time.

 

1) Add the inputs and the outputs to the icon connector to let LV know that it can not cheat and figure out the answers before the game starts.

2) Use very large arrays to do your benchmarking.

3) Use the high precious time function.

4) Repeat all of your test runs multiple times and take the average to decide which is fastest.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 2 of 9
(4,550 Views)

"high precious time function" (resisting some funny remarks about all time being precious) should be: "high precision time function".

 

For instance use "high resolution relative seconds.vi".

 

0 Kudos
Message 3 of 9
(4,503 Views)
Solution
Accepted by topic author Superwoman123

There was an NI Week 2016 presentation on Benchmarking and Code Optimization you might be interested in: Code Optimization and Benchmarking


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 4 of 9
(4,497 Views)

wiebe@CARYA wrote:

"high precious time function" (resisting some funny remarks about all time being precious) should be: "high precision time function".

 

For instance use "high resolution relative seconds.vi".

 


It is just too tempting not to post...

 

Spoiler

 

This thing all things devours:
Birds, beasts, trees, flowers;
Gnaws iron, bites steel;
Grinds hard stones to meal;
Slays king, ruins town,
And beats high mountain down.

  • Spoiler
    One of Gollum’s riddles for Bilbo. The answer is “time”.

 

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
Message 5 of 9
(4,479 Views)

Too bad bugs aren't in that list.

0 Kudos
Message 6 of 9
(4,469 Views)

Is there are more efficient way to multiply adjacent elements of a 1-D array of signed integers. The 3 attached vis are the best i could think of. Please advice. Thank you for the response.

0 Kudos
Message 7 of 9
(4,439 Views)

You need to be careful with integers, because the product of two might not fit in the valid range of the datatype. For your U8 arrays, the output could be needing all of U16. All your examples use unsigned integers (U8), why are you now talking about signed integers? Overall, it should not matter much.

 

Both versions with FOR loops are identical, because your inplace structure makes no difference. The LabVIEW compiler already operates in-place as much as possible.

 

Of course you could replace the "index array" and "array subset" with a single instance of "delete from array" for simplicity.

 

MultiAdjacent.png

 

The one with the array subset might be faster (SSE?) but requires allocation of two arrays, so more memory. Still, that's what I would probably use.

 

Unless your arrays are gigantic it is pointless to even worry about such a simple operation.

 

Just from looking at the code, we cannot tell which version will result in the most optimized code. Chances are that the compiled code is very similar for all versions.

0 Kudos
Message 8 of 9
(4,429 Views)

Optimising this is only useful if it's a bottleneck. Don't optimise until needed.

 

This routing will only be a bottleneck if a) the arrays are huge and\or b) you call it hundreds\thousands of times per second. If not, why bother.

 

If this routine is a bottleneck, the only thing left to do is to avoid doing it.

 

For instance, if only one input element changes, only update the relevant output elements. Or if possible, don't calculate them, until you need to read one element, then calculate only that element. Classes help for that, because it's a lot easier to keep (temporary) values bundled in the object's private data and passed in shift registers.

 

If you work in development mode, turning off debugging might help a bit, you already get this in executables (unless you turn debugging on explicitly). Setting the VI to inline might help, although it's usually not worth the trouble.

Message 9 of 9
(4,416 Views)