Improve Diagram Disable performance

[MGiacomet]

Adding a Diagram Disable to NOT run some portions for the code shoulg NOT increase execution time.

I could understand it, while running under development mode, but when building the VI into an .EXE, that's preposterous!

Please fix Diagram Disable so that by adding one to NOT run some code, does not increase execution time.

[AristosQueue (NI)]

I've asked someone to evaluate this as a bug report, but this might not be a bug: as with your other performance post, have you turned off debugging on the VI before doing your benchmarks?

Please be aware: building an EXE does not turn off debugging on VIs even if you check the checkbox in the build options that would seem to do this. Personally, I think this is the most twisted part of LabVIEW, but, regardless, when you build an EXE, you have to actually save your VIs with debugging turned off if you want the EXE to not include debugging. This is documented in various places but is very poorly understood by users (myself included until recently). Benchmarking without debugging disabled may show unexpected performance results.

If you have not turned off debugging then, yes, the diagram disable structure will introduce performance hit because the structure node -- any structure node -- introduces a diagram break in order to allow execution highlighting to behave properly.

[X.]

Regarding the "debugging not turned off" when releaseing an exe, there ought to be an easier way to force all VIs to not run in debug mode in an exe than going through every single VI to check whether this option is turned off, turn it off if that's not the case, save the VIs, release the exe, go back to those VIs that need occasional debugging, turn debugging back on and save the VIs again.

[AristosQueue (NI)]

X: I agree with you.

[AristosQueue (NI)]

MGiacomet:

Report from developer on the compiler team:

I recreated the user's VI in 2015 (32-bit), turned off debugging, and put a loop around that to run the code 1000 times and record the average run time. Doing this, I have not seen any variance between when there is a Diagram Disable structure around the constant or not (12.23 ms without DD and 12.25 ms with). I also wanted to extend it to an application with longer expected runtime, and that showed similar behavior to the previous test (1817.6 ms without DD and 1800.9 ms with).

We have some specific machines to use for this kind of benchmark testing to rule out skew caused by OS event interruption or other processes, so I trust these numbers.

End result: I'm going to get this idea moved to Decline. There's nothing wrong with the LV compiler when it is allowed to apply optimizations. But you do have to turn off debugging to get most of those optimizations.

[Darren]

Declined for reasons listed here: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-Diagram-Disable-performance/idc-p/3253564#M343...

[MGiacomet]

This is the most "head-in-the-sand" posting from NI!!! What??? Do you expect the user to manually turn debugging OFF on (my case) 4000 VIs???? Then remember to turn them back ON, minding the ones that I purposefully have debugging off, so I don't step into them while debugging? As posted by X, there should be an easier way. Please stop shooting down ideas before the community has had a chance to chime in. This is shoddy, arrogant customer service.

[MGiacomet]

Furthermore... Even with debugging enabled, what "debugging" can be done with code that has been disabled by a Diagram Disable element???

[X.]

The problem as I see it is that to turn debugging off before releasing an exe requires keeping track of the status of all VIs, and reset them to that original status afterwards. If this could be done without flagging the VIs as modified (that is, without having to save the VIs), then a " Before Build" and an "After Build" VIs could be written to do that. I hate to have dozens of VIs flagged as modified after the process and have to commit them in version control for no good reasons.

I suppose if changing the debug flag back to its original state could be done by a simple scripted undo, we should be able to do that?

[Mads]

AristosQueue wrote:
"Please be aware: building an EXE does not turn off debugging on VIs even if you check the checkbox in the build options that would seem to do this. Personally, I think this is the most twisted part of LabVIEW, but, regardless, when you build an EXE, you have to actually save your VIs with debugging turned off if you want the EXE to not include debugging."

This should be defined and fixed as a bug. I do not know of anyone who has not assumed that the consequences of debug flags/structures on/in a VI were all removed when building an executable. Unless the user explicitly enables debugging in the executable there really is no reason to build the application non-optimized. The exclamation mark next to the "Enable debugging" feature in the application builder is just a bad excuse. It does not address the real world expectations and needs of the users.

[jcarmody]

I learned about "The Principle of Least Astonishment" just yesterday - http://thecodelesscode.com/case/223