LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Showing results for 
Search instead for 
Did you mean: 

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

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


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.



Active Participant
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.
Active Participant
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.
Knight of NI

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.

LabVIEW Champion. It all comes together in GCentral GCentral
Active Participant

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.

Check out ClampOn CAN Monitor on the LabVIEW Tools Network.
Knight of NI

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)


LabVIEW Champion. It all comes together in GCentral GCentral
Proven Zealot

> 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.

You could use a radio: Force enable debugging, Use Source File Settings, Force disable debugging
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.
Active Participant

Queue DOS

Trusted Enthusiast
Trusted Enthusiast

@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...