Jump to content

VI Performance Tuning: Allow Debugging of Password Protected VIs


Jim Kring

Recommended Posts

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 :)

Link to comment

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

  • Like 1
Link to comment

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 :)

Link to comment

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.

  • Like 1
Link to comment

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

Link to comment

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.

  • Like 1
Link to comment

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>

  • Like 1
Link to comment

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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.