Performance improvement for password protected add-ons by disabling debugging

[Jim_Kring]

There's a discussion happening on LAVA where we're learning that, apparently, disabling debugging helps the performance of password protected VIs.  So, if you're password protecting your add-on (and leaving block diagrams, in order to have cross-platform compatibility and upgradability to new LabVIEW versions) you should consider disabling debugging for your add-on VIs, for %20 performance improvement when running in the LabVIEW IDE (since users won't need to debug password protected VIs, anyway -- they can't access the block diagram).  Note that built LabVIEW applications will already see this performance improvement and we're only talking about performance when running inside the IDE.

[AristosQueue (NI)]

You're learning that disabling debugging helps the performance of VIs, which is pretty much what the documentation says it does. Nothing NI has ever said has implied passwords have anything to do with that, one way or the other.

🙂

Message was edited by: AristosQueue

[Daklu]

AristosQueue wrote:

...which is pretty much what the documentation says it does.

Yeah, but we're engineers and scientists.  We don't read documentation.

[crelf]

AristosQueue wrote:

Nothing NI has ever said has implied passwords have anything to do with that, one way or the other.

Message was edited by: AristosQueue

The data in the graph in the LAVA thread suggests otherwise - that having debugging on and a passworded VI is slightly faster than a VI with debugging on an no password protection. What gives?

[rolfk]

I would consider that difference as pretty insignificant, and possibly an artefact of the graphing software to not make one hide the other.

[JeffBoettcher]

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.

[crelf]

rolfk wrote:

I would consider that difference as pretty insignificant, and possibly an artefact of the graphing software to not make one hide the other.

I would be very upset with any graphing package that changed my data so it looked prettier (I'm looking at you Excel!), and I don't know if I could make the call on whether the difference is insignificant - it might be insignificant in one instance, and significant in another.

[AristosQueue (NI)]

Christopher Relf wrote:

The data in the graph in the LAVA thread suggests otherwise - that having debugging on and a passworded VI is slightly faster than a VI with debugging on an no password protection. What gives?

I'll wager a bug in the benchmarking, like one has the panel open and the other didn't, or an unsaved change kept the panel in memory. Failing that, I'll raise a host of other objections to any benchmark graph with that narrow a deviation unless it is run on a bank of 30+ separate but identical machines and averaged. Address in memory, priority of L2 caching, some windows event happening along, and on and on and on. There's nothing in the code to suggest a causal relationship.

(For the record, LV R&D now ignores most single machine benchmarking... we found that they just don't mean much when two identical installs of LV on identical HW can see 80% swings in performance based on how many times the benchmark has been run or which track on disk the installer happened to hit. Modern machines have too many moving pieces, and an individual no longer has the ability to do meaningful bencharks of his/her own code to such a fine grain. Even big separations are only suggestive until replicated by the grid.)

Message was edited by: AristosQueue

[Jim_Kring]

AristosQueue wrote:

You're learning that disabling debugging helps the performance of VIs, which is pretty much what the documentation says it does. Nothing NI has ever said has implied passwords have anything to do with that, one way or the other.

🙂

Message was edited by: AristosQueue

I agree with Daklu (that engineers tend to not read documentaiton), but would go one step further.  Modern software (that's very well designed) should, IMO, not require reading documentation in order to use it (e.g. Have you read the documentation for your iPhone? My guess is that most of its features are not fully documented anywhere (publicly). Rather, the features are designed so that humans, even my two year old, will learn how to use it -- ask Dr T what he thinks about "insanely great products").  So, even if the documentation has never implied something, if my human intuition makes me feel that the software should do something, and it doesn't, then it creates a cognative dissonace that I classify as a usability bug (in the software, not my brain ).

Fun debate

-Jim

[AristosQueue (NI)]

Jim: I don't buy the argument in general.

Try giving a person, a human being, instructions to do a task without speaking their language. Or if you do speak the same language, without grasping their cultural background. Programming isn't using. It's instructing. We can do an awful lot to make it simpler, but at the end of the day, you have to understand what you want to have happen and express yourself properly. Sure, we can make commands at ever higher levels, and do, but you still have to express complex thought. You don't do that with a dumb device. Try using Siri exclusively to control your iPhone and let me know when you'd like a manual of commands she actually understands. You can do a lot, but a lot of simple stuff doesn't work out.

As for human intuition, even having an intuition about something as alien as a foreign intelligence's way of viewing the world is a flaw that just gets in the way of understanding what is really going on. Stop having that. It will serve you better in the long run when intelligences like Siri are more prevelant in your environment. And it will make you a better programmer in the short run ... APIs make a lot more sense when you reason about them than when you intuit about them, regardless of who wrote them.