Jim Kring Posted September 14, 2012 Report Share Posted September 14, 2012 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 Quote Link to comment
Popular Post Darin Posted September 15, 2012 Popular Post Report Share Posted September 15, 2012 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. 3 Quote Link to comment
Jim Kring Posted September 18, 2012 Author Report Share Posted September 18, 2012 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). Quote Link to comment
Darin Posted September 19, 2012 Report Share Posted September 19, 2012 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. 1 Quote Link to comment
Aristos Queue Posted September 19, 2012 Report Share Posted September 19, 2012 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. 1 Quote Link to comment
asbo Posted September 19, 2012 Report Share Posted September 19, 2012 Any ideas what makes up the performance gap between Debug and Debug + PWD? 1 Quote Link to comment
Darin Posted September 19, 2012 Report Share Posted September 19, 2012 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. Quote Link to comment
Jim Kring Posted September 19, 2012 Author Report Share Posted September 19, 2012 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 Quote Link to comment
Aristos Queue Posted September 19, 2012 Report Share Posted September 19, 2012 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. 1 Quote Link to comment
Jim Kring Posted September 19, 2012 Author Report Share Posted September 19, 2012 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.] Quote Link to comment
crelf Posted September 19, 2012 Report Share Posted September 19, 2012 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... 1 Quote Link to comment
Jeff B Posted September 20, 2012 Report Share Posted September 20, 2012 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. 1 Quote Link to comment
Darin Posted September 20, 2012 Report Share Posted September 20, 2012 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> 1 Quote Link to comment
Jim Kring Posted September 20, 2012 Author Report Share Posted September 20, 2012 <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... Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.