gregstoll

You should have several from me from last night .

2012 kept crashing, then hanging. Forcing recompile on each Actor Core.vi, saving all, mass-compiling (for good measure), and restarting LV eventually got it working again. I think the troubles began when I changed some reference controls in a STD that is part of the private data in one of the actors. (I can submit this project to NI, if that's useful. Maybe if I get a repro, first.)

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!

I'm guessing this means no switch to the UI thread, presumably similar performance to a local variable?

Yup!

Control value by index seems neat but I think there are other ways to do the same thing

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

So that's pretty definitive. It looks like it checks. But I would still like to understand what the issues are i.e. what makes a LabVIEW dll different from a C dll apart from feature support

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.

If you create the library using the LabVIEW build process, then the user should have that version of the run-time. The main reason for this, however, is more to do with the supported features that you may put in the dynamic library rather than the compilation process (although NI tends to use different compilers with each version - so it is also a safer bet for that reason). Therefore it is possible to load a  LabVIEW 2009(32 bit,) built library in an executable built in LabVIEW 2012(32 bit) with the 2012 run-time, but it will not be possible to load a 2012 built one in 2009 with the 2009 run-time if you have used features that are unavailable. This just pushes the maintenance overhead downstream to the installer. Similarly, a dynamic library built in 2009 can be loaded in the IDE of, say, 2012. If you do this,however, you need to test, test, and test some more.

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.

I get many error prompts (error 1026 occured at Close reference-vi ref invalid) when scanning either a directory or a project. I can get file output and do analysis though.

Ah, thanks - I forgot to turn off automatic error handling. I've posted a new version of the code that should fix the problem.

Interesting little project that opens up a couple of possibilities (like automagically in-lining those identified as capable of being in-lined). Maybe it can be used for older versions by running it in 2012 and back-saving to a previous version (2010/2011?). Can it be extended to include or say something about subroutined vis?

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.

A bit of documentation wouldn't go amiss as to what "complexity" actually means and what can be gleaned from it. I assume a complexity of >5 is "too complex"? Does this mean it is a candidate for refactoring?

If a vi is marked as "Partially Optimised", what does it mean and what can be done about it, if anything? etc.

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

So, in the case described here, does that include not allocating the "Indices of removed elements" array before the For loop? If so, I'm pretty impressed.

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