Jump to content

Compiled Code Complexity analyzer for LabVIEW 2012


Recommended Posts

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

Link to post
Share on other sites

(is it kosher to spam LAVA with links to forum posts? If not, my apologies...)

Typically, it's preferred to find the most specialized area of the forum that fits your post and just make one thread there.

Link to post
Share on other sites

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?

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.

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.

It Needs a bit of love ;), but very interesting.

Edited by ShaunR
  • Like 1
Link to post
Share on other sites

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!

Link to post
Share on other sites
  • 6 months later...

What is the impact of this Code Complexity threshold on built applications? I'm hoping that it has no impact, that when you perform a mass recompile or build into an application that all compiler optimizations are enabled, since the editor response time isn't really part of the equation. Can someone confirm this is true for me?

Link to post
Share on other sites
What is the impact of this Code Complexity threshold on built applications?

 

The app builder uses the same value as the IDE to decide whether to do full optimizations. You could have a pre-build step which sets the global property to a low value (or is it high? I don't remember) to get more VIs to be optimized and a post-build step to reset the property.

  • Like 1
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By farzane lk
      Hello
      I have received a LabVIEW dll and the corresponding header files so that I can send a trigger to a skin stimulation device.

      when I use the loadlibrary command in my Matlab script, I receive these two errors:  "We don't know the Compiler" and "We don't know the ProcessorType architecture"
      Which means while reading the "platdefines.h", the Compiler and the ProcessorType does not match the ones listed in ifs.
      I have set c++ compiler to visual studio 2015 in Matlab. (also tried MinGW). the system I`m using is Windows 10 (tried on 7, too), 64bit.
      I read somewhere that manually defining the ProcessorType and the compiler might solve the issue. But the problem is I Don`t know what they are. (when these two conditions below are not accepted.)
      #elif defined(_MSC_VER) || defined(_NI_VC_)
              #define Compiler        kVisualC
      #elif defined(_M_X64)
              #define ProcessorType    kX64
      --------------------------------------------------
      How should I find out the ProcessorType and the compiler I have? 
      I`d be EXTREMELY THANKFUL for any solutions you can think of.
      P.S.1 I attached all the headers and the Matlab error.jpg
      P.S.2 The code seems to work fine on manufacturers system with Matlab 2011. so it may be Matlab-related, but I don`t get how since the error is from platdefines header file.
       
      extcode.h
      fundtypes.h
      hosttype.h
      ILVDataInterface.h
      ILVTypeInterface.h
      lv_epilog.h
      lv_prolog.h
      platdefines.h
      STIM.aliases
      STIM.dll
      STIM.h
      STIM.ini
      STIM.lib

    • By Taylorh140
      I have never gotten the performance that I desire out of the 2D picture control. I always think that it should be cheaper than using controls since they don't have to handle user inputs and click events etc. But they always seem to be slower.
      I was wondering if any of the wizards out there had any 2d picture control performance tips that could help me out?
      Some things that come to mind as far as questions go:
      Is the conversion to from pixmap to/from picture costly?
      Why does the picture control behave poorly when in a Shift register?
      What do the Erase first settings cost performance wise?
      Anything you can think of that are bad ideas with picture controls?
      Anything you can think of that is generally a good idea with picture controls?
    • By flowschi
      Hello,
      I am using the variantconfig.llb for saving/loading configuration files.
      Unfortunately these configuration-files got very huge: 10.000 lines or even more, having hundreds of sections.
      Loading these files takes 15-30 seconds. The workflow:
      - getting all sections with "Get Section Names.vi" (is very fast)
      - a for-loop is using "Read Section Cluster_ogtk.vi" on each section Name (using Profiler, I can see that this uses the most amount of time). Depending on the section name, I am selecting the cluster type.
       
      Do you have any hints, how I can speed up the process?
      Thanks!

    • By madskg
      I'm using a Labview Shared Library (DLL) to comunicate between a C# program (made by another company) and a labview Executeable (which means different processes) on the same PC. Currently i'm using network published shared variables, to communicate between the Labview DLL and the LABVIEW program (both made by me) which works well, except for the performance.
       
      Each time the DLL is called it needs to connect to the shared variable, which takes between 50 and 300 ms. When it is connected, the data transfer is instant. I have tried to use the PSP "Open Variable Connection In Background", which is a bit faster, because it doesn't wait to verify the connection. But it still adds some overhead.
       
      I have also tried to use notifiers from this example: https://lavag.org/topic/10408-communication-between-projects/ . Opening connection and sending the notifier takes 50 - 100 ms.
       
      I guess both the notifier and the shared variables are "slow" because they use the network communication, even if it is the same pc both programs are running on (localhost).
       
      Does any of you know of a faster method of communicating between a program that is running continuesly (connection open constantly) and one only exectuted when new data is ready (connection "re"-opened on every instance)?
       
      Thanks in advance.
       
      Best Regards
      Mads
       
       
       
       
       
       
    • By Manudelavega
      Before making the switch from LV2011 to LV2014, I ran the exact same test with the 2 versions (2011 and 2014) of my application. I recorded the CPU usage and discovered a huge deterioration of in LV2014.
       
      Is anybody aware of any change between LV2011 and LV2014 that could impact the performances like this?
       
      I should mention that the unit on the Y-scale is %CPU and the X-scale is MM:SS

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.