gregstoll

I can take a quick look at the reports - send me a message with one of the report IDs and I'll pull it up.

A gentle reminder: sending in reports when the NI Error Reporting dialog pops up helps us make future versions of LabVIEW more stable!

Yup!

As I worked on this, I feel obliged to chime in :-) There are definitely other ways to do the same thing, and they're pretty much all easier than using Set/Get Control Value by Index. The reason you would want to use Set/Get Control Value by Index is that it's very fast - just barely slower than wiring directly to an indicator. So it's useful if updating control/indicator values is something you're doing many times a second - otherwise there's no reason to switch to it.

Another vote for Newsblur - been using it for a few years now and been very happy. (plus it's by an independent developer and it's open source!)

I wasn't around when we made this decision, but I would guess the rationale was something like the following: Backwards compatibility would be a big burden for us. Every time we made a change to the execution system, we would have to consider how older code would behave with the change. It would increase our testing burden and make execution bugs (the worst kind of bugs!) more likely. It would make some kinds of big architectural changes (like the DFIR compiler rewrite) even more scary, and we'd be less likely to take on that risk. It would make the run-time engine bigger. Now the C runtime is backwards compatible (I think?), but I'd imagine they aren't adding as many new features as we are. The pain is also eased because you get a C runtime installed with the operating system.

This is not entirely correct. Let's say you have a LV 2009 32-bit built library (i.e. a .dll). You always need a 2009 32-bit run-time engine to load this! The one exception is if you're in the LV 2009 editor on Windows, but in that case you should have the run-time engine installed anyway so it's a moot point. It is not the case that a LV 2012 run-time engine can load a LV 2009 built library, no matter what features the built library uses. The same is true vice versa - the versions have to match for it to be able to load. (although 2009 SP1 and 2009 count as the same version for these purposes)

Just for reference, one reason the formula node is often slower than the equivalent primitives is that it doesn't go through DFIR optimizations, which we've spent a lot of time on since LabVIEW 2009. Now the MathScript node does go through DFIR, etc., so I'm surprised to see it being slower - you may want to talk to someone who knows more about that to see what the deal is.

Anecdotally, I remember someone saying that hyperthreading can make VIs execute less efficiently in some cases, although I don't remember what those cases are.

Ah, thanks - I forgot to turn off automatic error handling. I've posted a new version of the code that should fix the problem. Ah, it certainly could do that - at its core (complexity data.lvclass:create from VI.vi) it's just getting some properties from the VI, so that certainly could include subroutine VIs, or you could save it for previous and get rid of the code complexity stuff. There are new topics in the LabVIEW help about this, but briefly: "Code complexity" is a new metric based on the complexity of the compiled code. By default, if a VI's code complexity is >5, we will turn off some compiler optimizations to speed up compile time. (this is configurable in Tools->Options->Environment->Compiler) So VI's that are that complex are definitely a good candidate for refactoring. Thanks for checking it out!

I've posted information about a new help topic in LabVIEW 2012 about optimizing built application performance. Here's the link: http://forums.ni.com/t5/LabVIEW/Optimizing-built-application-performance-in-LV-2012-and-earlier/td-p/2121710. Greg Stoll LabVIEW R&D

Hi all - I've just posted a tool to analyze compiled code complexity of VIs in a project at http://forums.ni.com...12/td-p/2121692. Note that compiled code complexity is a new feature in LabVIEW 2012, and so this won't work with earlier versions. I'd be happy to answer any questions here or on the forums! (is it kosher to spam LAVA with links to forum posts? If not, my apologies...) Greg Stoll LabVIEW R&D

Yes - for unwired outputs in an inlined VI, we will dead code eliminate anything that is only used for that output (since it looks like the output of a node that no one's using). If you have particular VIs you want me to verify I can do that, but I'm pretty sure it should work. Inlining is neat!

Just bought my ticket - looking forward to it!

Hi JG - You are correct - this is a result of the way we treat Polymorphic VIs in AppBuilder. After stripping the PolyVI, the caller is broken because it's trying to call a private VI. Our suggested workaround is (as you discovered) to turn off "Remove unused polymorphic VI instances" in the build specification. This issue is tracked internally as CAR #212136. Greg Stoll LabVIEW R&D National Instruments