Compare performance of vis

[Superwoman123]

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.

[Ben]

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

[wiebe@CARYA]

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

[crossrulz · Accepted solution]

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

[Ben]

---

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

[wiebe@CARYA]

Too bad bugs aren't in that list.

[Superwoman123]

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.

[altenbach]

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.

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.

[wiebe@CARYA]

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.