Improved performance with additional tunnels?

[Rüdiger]

Hello everyone,

 

I have been sent here by NI Support, as they were not able to explain the behaviour to me.

I have created a little demonstrating VI, that shows some weird behavior:

 

When I go into a for loop with some data, the runtime depends on the amount of data i transfer/collect with outside bound autoindexing tunnels.

The weird thing is, that it executes faster if I collect data, for example I get the following values:

# Tunnels = 0 => mean runtime 37 ms

# Tunnels = 1 => mean runtime 37,5 ms

# Tunnels = 2 => mean runtime 35,2 ms

# Tunnels = 3 => mean runtime 47 ms

The attached VI is LV 2015, but the images should give enough explanation.

If someone could explain this to, this would be great. 

 

Thanks in advance

 

Rüdiger

 

LAVA Test VI Performance.vi

Edited July 19, 2016 by Rüdiger

[ensegre]

Obscure compiler optimizations I would guess. Possibly platform dependent, maybe related to the fact that you create buffers for the empty arrays at the unconnected exit tunnels. Hint: show buffer allocations, I note that for example a buffer is shown as created twice on the output logic array for case 0, and once for case 1.

For the limited value that this kind of benchmarking has on a non-RTOS, I get slightly different timings, with a minor decrease between 0 and 1 rather that between 1 and 2:

0 23.96-0.35 24.04-0.20 24-0.29
1 23.6-0.58
2 25.56-0.58 25.52-0.51
3 33.32-0.69

I also remark that timings change slightly if I remove case 3:
0 23.88-0.38
1 23.69-0.49
2 24.41-0.51

and further decrease if I delete the clock wire inside each case connecting to the unused input tunnel of the outermost loop.

 

 

 

 

Edited July 19, 2016 by ensegre

[ned]

Note that you should move the # Tunnels input outside the For loop, since otherwise you could change that value while the loop is running, and LabVIEW has to account for that possibility. There's also debugging issues here - the additional tunnels are places where LabVIEW needs to allocate memory in case you put a probe on them during execution, but maybe that's actually helping here by changing the way LabVIEW reuses memory. Of course, if you disable debugging, the VI executes instantaneously because it optimizes out the unnecessary For loops. I am seeing the 2 tunnel case fastest at 29ms, the 1 and 3 tunnel versions nearly identical and barely slower (30.5ms), and the 3-tunnel version slowest at 39.5ms.

I don't think you're learning much from this sort of benchmark when you have debugging enabled and code that could otherwise be optimized out.

[ShaunR]

3 hours ago, Rüdiger said:

I have been sent here by NI Support, as they were not able to explain the behaviour to me.

 I'd expect at least a "clumping optimisations" hand-wave from paid support rather than a "dunno, ask someone else". The gesture controlled quad copter making it too dangerous to walk upstairs to ask R&D?   

[LogMAN]

4 hours ago, Rüdiger said:

I have been sent here by NI Support

Wild guess: LabVIEW uses the "Delete From Array" function in case 0 to dispose of used elements as soon as possible. For cases 1 and 2 it uses "Index Array", thus does not free the memory (the original array is just passed to the output tunnel and freed afterwards in one go). Case 3 is less efficient as the final 2D-Array takes time to build (requires re-allocation in memory in worse case).

Maybe ask NI support? Oh wait...

[jacobson]

I would be interested in what happened with that support interaction if you are okay with PMing me the service request number. Aside from that I would agree with Ned, but I wasn't able to figure out a way to test this where everything wasn't completely optimized out or where the differences in execution timing couldn't just be explained by the changes that I had to make for LabVIEW to not optimize it out.

[Rüdiger]

Thanks a lot for all those quick answers. I did not expect that.

I'm aware that benchmarking this kind is very quick and dirty on non-RTOS. As soon as I have access to a colleagues PC (where the original problem VI is) I can upload that VI, as it shows a greater impact in performance than my specially created VI.

@ensegre Thanks for the hint with the buffer allocations. Now I see at least, that even if I connect the input elements to an autoindexing output tunnel, there is no additional buffer allocation.

@ned : You're absolutely right with the #tunnels control, Thanks for the hint with disabling debugging. Usually it is hardly influencing subVI runtime in my VIs

@ShaunR In my case, the support team has to cross the atlantic ocean, as I asked the german support team. But they offered me to escalate it to the US colleagues, saying an answer can take a looooong time. That's why I asked here.

@jacobson I guess I will leave it like it is, as the support guys are doing there best and offered redirecting to people who maybe know better (US colleagues or LAVAG users). And one of the 2 proposals works fine so far.

 

 

[ShaunR]

4 hours ago, Rüdiger said:

 

@ShaunR In my case, the support team has to cross the atlantic ocean, as I asked the german support team. But they offered me to escalate it to the US colleagues, saying an answer can take a looooong time. That's why I asked here.

@jacobson I guess I will leave it like it is, as the support guys are doing there best and offered redirecting to people who maybe know better (US colleagues or LAVAG users). And one of the 2 proposals works fine so far.

 

 

"Resolved to customers satisfaction" it is then.

FWIW. Escalation can be very quick or many days. It's only the time-zone differences that make the delay if (and this is a big if) the application engineer knows who to contact and can articulate your concern. This is why examples are so important.

Once you have found a well connected application engineer that you can ask for by name to get past the front door bouncers - 24 hours max for a useful response.. As en ex European.  - a telephone call with a follow up email (with example and bulleted list of questions) at 4pm and you will usually have the result sitting in your inbox in the morning .

That named engineer is now your dive buddy (as much as they might resist ) in the murky waters of NI support procedure. Hold on to them as if your life depended on them because your sanity does