VI Performance Tuning: Allow Debugging of Password Protected VIs

[Jim Kring]

I'm could probably test this, myself, but I'm pretty lazy busy.

Is there any performance benefit of disabling the Allow Debugging VI property on a VI that is password protected? Meaning: does a password protected VI sort of have debugging disabled (and gain the associated performance improvements) while it's diagram is locked?

Thanks for helping me avoid hard work find the answer

[Darin]

Here is some benchmarking of a Quicksort Implementation where I adjusted the settings of the subVI: No debugging, debugging, debugging + password. I'll let you be the judge, subVI was saved and closed for all three tests.

[Jim Kring]

Darin: Thanks a bunch for the benchmarking and data. The results do speak loudly. This will make a big difference for our application, I think (~20% performance increase when running the code in the IDE).

[Darin]

It was a very interesting question, I can see the logic of disabling debugging when you are already unable to debug. Of course my overriding philosophy is that the IDE should do exactly what I ask (enable or disable debugging/ add or remove pwd), no more and no less.

As to the performance kick, disabling debugging is often one of the best things you can do for code running in the IDE. So much so that I once submitted an idea to make it much easier to do. However, some people who shall remain nameless were less than enthusiastic about it.

[Aristos Queue]

Debugging is a setting that requires changing compilation. Entering the password can be done without recompiling. Thus having a password does not imply turning on or turning off debugging. They're completely independent settings.

[asbo]

Any ideas what makes up the performance gap between Debug and Debug + PWD?

[Darin]

I will have to do some further tests to see if there is a significant difference. The data sets and algorithm are both randomized so that may play a role as well as test order. My guess is that the difference with simply adding a pwd is not significant.

[Jim Kring]

Debugging is a setting that requires changing compilation. Entering the password can be done without recompiling. Thus having a password does not imply turning on or turning off debugging. They're completely independent settings.

True. Still, there's a usability opportunity, here. I'd argue that most users aren't concerned about a recompilation and would prefer to have LabVIEW automagically give them better performance when they password protect something. That's part of why we all love LabVIEW so much: it worries about (re)compilation and we don't

[Aristos Queue]

True. Still, there's a usability opportunity, here. I'd argue that most users aren't concerned about a recompilation and would prefer to have LabVIEW automagically give them better performance when they password protect something. That's part of why we all love LabVIEW so much: it worries about (re)compilation and we don't

Ah, but you can open a password protected diagram while the VI is running. You can't turn on debugging while it is running.

[Jim Kring]

Ah, but you can open a password protected diagram while the VI is running. You can't turn on debugging while it is running.

Yes, but (when a password protected diagram is opened while it is running) LabVIEW could (if the smarts were added) defer the enabling of debugging until after the VI stops running.

Regarding use case frequency:

- The number of times I've wanted to debug a password protected VI while it was running (and where I couldn't afford to stop and restart it) is zero.

- The number of times I've wanted better performance of password protected VIs is all the time (why not, right?).

Also, shouldn't users of password protected VIs be able to disable debugging (in order to benefit from the increase in performance) without knowing the password? Right now, they can't and that doesn't seem fair [update: I guess they could do this by resaving without block diagrams, but that doesn't seem very practical.]

[crelf]

Any ideas what makes up the performance gap between Debug and Debug + PWD?

I second this question. I know it's not the original intent of the thread, but I think it might make for interesting reading...

[Jeff B]

I don't know a complete answer, but for one thing, if you save a breakpoint into a VI that's password-protected, when that breakpoint is hit, you're prompted for the password (if it's not in the password cache), and if entered, you can debug the VI. This ability can be pretty useful, and I'd be surprised if it didn't introduce a non-zero performance hit.

[Darin]

As I suspected, the difference between debug and debug+pwd is purely statistical. I will post some of the data if I get a chance, mostly I have learned that my slow laptop makes my slow home PC look good.

<OT>

On several occasions I have mentioned my desire for debug/release configurations like Visual Studio. This could control more than debugging, but also FP bounds so I easily can have off screen controls in the finished VI. At any rate, the current VI property dialog dance is a pain.

</OT>

[Jim Kring]

<OT>

On several occasions I have mentioned my desire for debug/release configurations like Visual Studio. This could control more than debugging, but also FP bounds so I easily can have off screen controls in the finished VI. At any rate, the current VI property dialog dance is a pain.

</OT>

Great point. In fact, I'm going to be working to tweak our fully automated build to programmatically adjust the VI properties. It would be nice if I had an easier way to adjust the disable debug setting. Maybe VIPM's package builder should offer such a feature...