LabVIEW

[gregstoll]

Hi all -

I've been working on a tool to analyze the compiled code complexity for VIs in a project/directory.  (this is a new feature in LabVIEW 2012) I've attached the tool below.  There are two steps to use it:

• Gathering the complexities: under gather complexities.lvlib, run one of "gather from directory or llb.vi", "gather from project.vi", or "gather from projects.vi" and specify where to read the VIs from and where to put the output.  This will generate a series of text files, one per subdirectory.
• Analyzing the complexities: under analyze complexities.lvlib, run "analyze complexities.vi" and point it at the directory with the text files in it.

The front panel of "analyze complexities.vi" looks something like this:

On the bottom is a histogram of code complexities.  Above that are some statistics (the most interesting being how many VIs were only compiled with partial optimizations), and to the right are all the VIs sorted in descending order of code complexity, so you can easily see the biggest ones.  It also finds VIs that could be inlined and have a low complexity, and shows them under "VIs to consider inlining".

I think this will be useful for larger projects for informational purposes, to find VIs that are "too big" and not being compiled with full optimizations, and finding VIs that are good candidates for inlining.

I'd be happy to answer any questions about the tool!

Greg Stoll

LabVIEW R&D

National Instruments

[gregstoll]

A user noticed some errors when closing VIs in the gather phase.  Here's a new version of the code.

Greg Stoll

LabVIEW R&D

[Ben]

---

gregstoll wrote:

... 

Greg Stoll

LabVIEW R&D

---

Hi Greg,

No traffic on posts like this generally means we don't get it.

I'll play along.

If I have been writting code for years that works fine and runs fast, why is this of any interest to me?

What is my motivation?

Ben

[gregstoll]

Fair enough - I'll do my best to motivate it :-)

If you have VI's with code complexity greater than 5, then that means

- they're not being compiled with full compiler optimizations, so they'll run slower than they could

- they're big and probably good candidates for refactoring

If you have VI's with very small code complexity, they're probably good candidates for inlining, which will make them run faster.

This project will help you find VI's in both categories.  (I'm into numbers, so I love the graph of the frequency of code complexities, but it's not that useful)

[Norbert_B]

Greg,

while i appreciate your effort, i would expect such features to be part of the VI Analyzer. In fact, inlinability (does this word exist at all?) is already tested with VI Analyzer:

 

So do you think it will be possible to integrate your effort for the compiler optimization analysis into VI Analyzer for e.g. 2012 SP1? 

Norbert 

[gregstoll]

Hi Norbert -

I chatted with Darren about this, and we decided that the tests that already exist in VI Analyzer make more sense, especially the "Complexity Metrics" ones since they call out specific things you can do to simplify your VI.  I will admit I didn't know there was an "Inlinable VIs" test...somehow I missed that.

[Norbert_B]

Greg,

but VI Analyzer does not (at least, i am not aware of it) tell you what compiler optimization level was used for the individual VI. I think this could be valuable information, too. And i understand that your tool does test this

Norbert