Add an option to disable debugging/enable optimization when building application

[MGiacomet]

There should be an option to fully enable optimization when building an application as to automatically remove performance impacts caused by diagram elements that shouldn't cause any.

As summarily declined by NI, this idea

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Improve-Diagram-Disable-performance/idc-p/3253939#M343...

shows that unless you manually go over ALL your VIs disabling debugging, Diagram Disables (that are supposed to not avoid executing some code!) you'll suffer a performance impact.

It is preposterous to expect the users to manually disable/reenable debugging on every single VI when building an application.

Please add an option to enable full optimization.

[GregSands]

In the meantime, a possible workaround could be to re-check out the source VIs into a temporary directory, so that rather than reenabling the debug status, the temporary files can just be deleted. Assuming you use some form of version control, that is. It's still painful though to run through and turn off debugging, and I agree it should be part of the application builder in the way you suggest.

[GuenterMueller]

GregS: That way only VIs residing in my repositories would be affected. All VIs LabVIEW comes with (and 3rd party stuff that is located somewhere in the LabVIEW folder) would not turn off debugging when running a Build Specification.

[altenbach]

Also note that a large collection of vi.lib tools (example: "nonlinear curve fit" and dependencies) have debugging enabled. These need to be stripped too when building. Ideally, nothing in vi.lib should have debugging enabled, but that is probably a new idea. Stay tuned.

[Mads]

Kudos. I think  the optimal(!) solution though would be to just make it work the way people have thought it was all along; the application builder should (on temporary copies, not permanently on the originals) turn off debugging flags, strip out disabled diagrams etc automatically when buidling unless the user has explicitly enabled application debugging. Anything is better than the current work-around though.

[altenbach]

Ideally, debugging should always be off in saved VIs, with an easy way to enable it when we actually want to debug one of the VIs that has the front panel currently open. (Yes, vote for this idea!).

If we edit code during debugging, a debugging free version of the code should be maintained and saved with the VI (or kept in the compiled code cache), while the debugging code should be kept in a temporary location that disapers once the VI closes.

Now we don't even need anything fancy in the builder.

The only drawback is that if we want to debug an executable (hopefully a small fraction of all builds), it will take significantly longer.

(Debugging should also be automatically enabled for VIs that are set to suspend when called, another setting that should only apply to the current edit session and should never get saved)

[AristosQueue (NI)]

> Ideally, debugging should always be off in saved VIs

Your view of "ideally" and mine are diametrically opposed. Ideally, anything I open in the IDE I can slap a probe or breakpoint down if midway through testing I realize that it is the heart of the problem. I shoudn't have to turn the options on on things before I start running.

[Oligarlicky]

You could use a radio: Force enable debugging, Use Source File Settings, Force disable debugging

[JasonCorwin]

Under Source File Settings of a Build Specification, there is an option to Customize VI Properties. In there you can override VI Properties and uncheck the Allow debugging option. Does that satisfy this need? It's still somewhat of a workaround, but less kludgy than the temporary files ideas. This option still needs some work. If you select a folder in a lvlib there is check box that appears, "Set VI properties for all contained items". The customized properties are then applied to all the VIs and class methods under that folder. But if you select the .lvlib or a .class file, the "Set VI properties for all contained items" does not appear, requiring you to select VIs one by one to override VI Properties.

[ToeCutter]

Queue DOS

[X.]

@JasonCorwin: this is a very good point. What's missing is to be able to apply it at the "My Computer" level, so that we don't have to go through all virtual folders (or libraries, or classes) one by one. Of course a workaround might be to have a top level virtual folder containing everything...