Help talk me into or out of this hack: a new conditional disable symbol

[mje]

21 hours ago, Aristos Queue said:

This comment is really bugging me.

To me, toggling debugging is the same as moving from Desktop to FPGA. The entire code base is compiled differently for the new target. I cannot see anything about the existing Enable Debugging option that is an existing hack...Can you expand your thoughts for me here?

I'd expect compilation to be different, how else will all the debug symbols get put in place? But what I don't expect is all the other stuff you said goes on. The text presented to me in the dialog says "Allow debugging." Not "Enable debugging, and constant folding, and loop invariant analysis, and target specific optimizations, and a bunch of other stuff."

I expect the checkbox to toggle letting me attach a debugger to the VI to perform various forms of debuggery. Stuff like breakpoints, probes, step execution. 

Taken directly from the LabVIEW 2017 context help:

Quote

Allow debugging

Allows debugging on this VI. For example, you can set breakpoints, create probes, enable execution highlighting, and single-step through execution. Remove the checkmark from this checkbox to reduce memory requirements and improve performance slightly.

I've been using LabVIEW since the 90s and had no idea other optimizations were tied to this checkbox until you mentioned it the other day. Nowhere had I ever read it was. It may be obvious to you, someone who's intimately familiar with the innards of LabVIEW, but LabVIEW.exe is a black box to me.

That's what I mean by hacked up. There's a discontinuity between the function and indication of that checkbox. The fact that the setting affects things other than debugging means one of two things: the setting shouldn't be used for these other purposes; or the function of the checkbox has not been clearly expressed.

I'm not trying to argue against having these optimizations and such. They're good and part of what makes LabVIEW so efficient. But since that checkbox really isn't "Allow debugging" and more "Allow pandora optimization", it may warrant some review of how the information is presented to the user?

You'll also be my hero if you can get the word "debuggery" into updated UI or documentation.

Edited October 10, 2017 by mje

[hooovahh]

25 minutes ago, ShaunR said:

I would like to see a case implemented for the "LabVIEW version"

Oh that's a good one and one I have used in the past.  I had found that in some versions of LabVIEW, some methods of doing functions were more efficient than others.  And so I would have the VI on start read what version of LabVIEW it was running in, and then do things differently based on if it was in 2015 versus 2016.  Of course there are other issues in that this needs to be saved in the oldest version supported, and that would generally mean not using some new features that might be more efficient.  But my point is I would have found LabVIEW version useful in the past.

[shoneill]

mje, to make things worse regarding the "Enable Debuggery" flag, what it ACTUALLY does is not only secret but also varies depending on the actual code complexity (real complexity, not what LV pretends it is) and the setting for "Limit Compiler Optimisations" in the Environment settings....

[Aristos Queue]

23 hours ago, hooovahh said:

 Other things I check I can see changing at run time like if the actor is in a subpanel I may behave differently, or if the VI has its window showing.

Right, but I'm asking for things that you could change at *compile* time. Anything that toggles at run-time is irrelevant to my question in this thread.

[Aristos Queue]

7 hours ago, mje said:

 Not "Enable debugging, and constant folding, and loop invariant analysis, and target specific optimizations, and a bunch of other stuff."

You have it backwards. In order to enable debugging, we have to turn OFF all that stuff. That's what allows debugging is doing away with all the optimizations of the code. The optimized code looks nothing like the block diagram and isn't amenable to exec highlighting, probing, etc. These aren't orthogonal things... enabling debugging MEANS turning off all the stuff that prevents debugging.

The documented reduction in memory and performance improvement? Turning off debugging allows all those things to kick in. The only error in the documentation to my eyes is the word "slightly".

Edited October 10, 2017 by Aristos Queue

[mje]

4 hours ago, Aristos Queue said:

You have it backwards. In order to enable debugging, we have to turn OFF all that stuff. That's what allows debugging is doing away with all the optimizations of the code. The optimized code looks nothing like the block diagram and isn't amenable to exec highlighting, probing, etc. These aren't orthogonal things... enabling debugging MEANS turning off all the stuff that prevents debugging.

I see, yes that makes sense. I get how that's a problem in LabVIEW since there is no lower level representation presented beyond the block diagram. For example when I debug my optimized gcc code I can always peer at the resulting assembly to get an idea of what's going on when code seemingly jumps from line to line or look at registers when a variable seemingly vanishes and never makes it's way into RAM. Without a lower level presentation, you're pretty much hosed with respect to debugging if any optimizations are enabled.

I withdraw my objection, especially since there's some reference to optimizations in the dialog if I recall.

Seriously though, thanks for taking the time to set me straight. Cheers, AQ.

[Aristos Queue]

20 hours ago, mje said:

I see, yes that makes sense. I get how that's a problem in LabVIEW since there is no lower level representation presented beyond the block diagram. For example when I debug my optimized gcc code I can always peer at the resulting assembly to get an idea of what's going on when code seemingly jumps from line to line or look at registers when a variable seemingly vanishes and never makes it's way into RAM. Without a lower level presentation, you're pretty much hosed with respect to debugging if any optimizations are enabled.

I withdraw my objection, especially since there's some reference to optimizations in the dialog if I recall.

Seriously though, thanks for taking the time to set me straight. Cheers, AQ.

No problem. It helps me to know how customers see the world... sometimes we can restate things in more intuitive ways. :-)