Showing results for 
Search instead for 
Did you mean: 

Enable Debugging's Affect on Performance

Go to solution

During development, my team enables debugging on all of our VIs so that we can troubleshoot them when they are rolled into our larger program architecture. When we build them, however, we disable debugging in the .dlls, packed libraries, and executables that are used in the production environment. Is there any downside to this? Is there any point to going through and disabling debugging for the individual VIs, or is that feature a wash after it is built? How much of a performance hit, if any, do we take if we leave debugging enabled all the time?

0 Kudos
Message 1 of 4

Your code will be larger (as there need to be "hooks" to allow Debugging to function) and potentially slightly slower.  If you are doing Real-Time, where determinism is important, and you need as much speed to do as much processing in the "free time" as possible, disabling debugging.  If you are not time-critical, then the few percentage points in Space and Time might not be worth the processing of all of your VIs (Projects can easily run over 1000 VIs).  There's also the inevitable "questionable behavior" (a.k.a. "bug") that surfaces two weeks after Release, when debugging "hooks" are very useful ...


Bob "My $0.02" Schor

Message 2 of 4

Do those "hooks" still exist in the .dlls, packed libraries, and executables if debugging is disabled in the build specifications?

0 Kudos
Message 3 of 4
Accepted by CodyTheEE

I may have answered the "wrong question".  I was talking about the VI Execution Property "Allow Debugging" (On by default).  Your most recent question was about the Build Advanced option "Enable Debugging", which is Off by default.  You definitely want it Off in your Production Release -- it definitely adds code and slowdowns (I think you can turn on Highlight Execution, but I may be wrong on that ...) to the Executable.


Note that in the Build Spec, it says "Disabling this checkbox does not ensure full optimization".  That's NI's way of telling you that it doesn't influence the "hooks" in your LabVIEW code if you have "Allow Debugging" checked.


As to whether there are debugging "hooks" in the .dlls, packed libraries, and executables, that depends on whether they are included in the Source specs (the "Allow Debugging" checkbox) and (in the case of executables) whether they are present in the Build Specs.  Remember, the defaults are "Debugging On" in the LabVIEW source files, "Debugging Off" in the LabVIEW Build specs, but that these have slightly different effects.


I have both "ordinary" and "Real-Time" code I've developed and maintain.  I've not turned off Debugging at the LabVIEW Source (even though my LabVIEW RT code, when I "inherited" it running in LabVIEW 7.0 had Debugging Off in order to run reliably at 500 Hz, when I re-developed it (a 100% rewrite) in LabVIEW 2012, I left Debugging On and can reliably run at 1000 Hz without (a) missing data or (b) having "display" stutters.  I didn't even know about the Debugging option in the Build Spec until this year when I was working through a LabVIEW Bug with an NI Applications Engineer who suggested I "run the Executable with Debugging turned on", and I said "You can't do that ...".  Oops.


Bob Schor

Message 4 of 4