See AristosQueue's comment on page 2 for reasoning. Basically, systems would take a huge memory and performance hit to add this functionality. A lot of developers really like this idea so we will continue to look for ways to implement this in a way that wouldn't affect performance. This is not possible in the foreseeable future though (~2 years) so I'm moving this idea to declined for now but it will definitely not be forgotten.
I would like the ability to probe the loop iteration terminal ("i" in For and While Loops) without the need to wire it to something (indicator, edge of structure,...).
I would like this idea extended to allow probes to be connected to any output terminal of subvi's. For instance, if I use a LabVIEW curve fit routine and would like to probe the standard deviation output terminal I now must hook up an indicator and they later remove it if I normally won't need it. There are any number of LV funtions for which I don't normally need all of the outputs but may want to probe them as a diagonstic when developing the application. Also, I would like to be able to hook a probe to a shift register that is normally not connected to an external wire.
I would really like the general case of this, the ability to probe a VI output terminal output without having to make an indicator. I would use this feature almost every day.
I just realized that no one from NI has responded to this thread. Several members of the compiler team looked into this idea earlier this year. We worked on this. And it is unlikely to happen. Why? It created a human-noticable performance hit when running VIs in the development environment for a wide swath of VI hierarchies.
Yes, you read that right. In order to be able to probe the [i] terminal, the value of [i] has to be available. The vast majority of the time, when LV is iterating, we do not need to have the value of [i] computed when the [i] terminal is unwired. We never need it when running a While Loop, and on a For Loop, more often than not, we can either use a pointer marching through the indexed array or we can play games like decrementing the value wired to the [N] terminal and comparing against zero. Adding the single 4-byte value for the [i] terminal to be probable caused a human-noticable performance hit in a huge number of apps in the development environment. How? The For Loop and While Loop are so common within LabVIEW (While Loop is the #1 most commonly used node, followed by Case Structure followed by For Loop) that adding that allocation triggered a cascade of register spills. Many very tight loops in deep, commonly used subVIs were suddenly taking time to write values back to memory that they weren't having to write because they could keep them in registers before this change.
On While Loops, there is no way to compensate. If the [i] value isn't being kept even when the probe is not present, there's no way to compute it on the fly when a probe is added. On For Loops, we could sometimes in theory recompute it only when the probe is dropped, but not always (when decrementing N for example, there's no original N value to subtract from).
It has been proposed that we could allow you to probe the [i] terminal *before* you start your VI running, and treat that as a reason to recompile the VI in order to provide the probe value. It would be the only probe that we have on the diagram that cannot be freely added while you are in the middle of a debug session. However, the biggest complaint has been that you can already wire out of the [i] terminal today if you know you need the value before you start debugging, and that's just not useful. Yes, making the [i] directly probe-able would decrease the number of mouse clicks on the diagram, but it still would require a recompile. And it would not be available for remote debugging, RT debugging, etc. Given all of those negatives, it doesn't seem worth it to add the feature.
Forcing the use of one more register on every loop is a major penalty for the compiler, and this just does not seem to be surmountable. As CPUs have gotten faster, a lot of things that used to matter have stopped mattering so much, as their cost savings dwindled below the human-noticable level, such that they were worth doing despite the performance hit. This one, apparently, has not yet hit that point.
The idea is still open at this time, as everyone is reluctant to mark it Declined, hoping that someone comes up with a nifty trick to make the feature viable. Maybe we'll just leave it open for a few years and see what new hardware gives us in the way of performance.
That's very interesting. So for speed, you should never wire from [i] unless you really need to?
It does suggest a possible solution: [i] should be hidden by default. Then if you need to use (or see) it, you show it (forcing a recompile). It would then be reasonable for [i] to be directly probe-able, in those cases where you want to see it, but only in the Probe context. But for all those tight loops, [i] is not present and so there is no slow down. It shouldn't break any existing code either.
A second advantage is that it gets newbies away from thinking of loops in terms of [i].
GregS: Use the [i] terminal. I am not waving you away from it. Your speed impact will be so negligible as to be unmeasurable on 99% of the VIs written in this world. The problem is the 1% of VIs that are parts of significantly deep hierarchies or that have very broad code reuse. And hiding the [i] terminal would just be a pain-in-the-neck from my point of view -- having to formally show terminals on nodes, especially commonly needed terminals, is not an aid to usability or readability.
For Loops should be thought of in terms of [i]. But if you're not using that number, LV doesn't have to actually compute it. It can remain a useful-but-theoretical construct.
See AristosQueue's comment on page 2 for reasoning. Basically, systems would take a huge memory and performance hit to add this functionality. A lot of developers really like this idea so we will continue to look for ways to implement this in a way that wouldn't affect performance. This is not possible in the foreseeable future though (~2 years) so I'm moving this idea to declined for now but it will definitely not be forgotten.
igagne -- doesn't help. We do not allocate a register for "i" terminal today even when debugging is turned on. Doing so for VIs that have debugging on would introduce significant cascade through the code and performance downsides, even if it was just user code (today all of VI.lib has debugging enabled and we'd have to turn that off for this feature).
