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.

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