OpenG Inline Improvements

[hooovahh]

This is likely a discussion that is similar to many others that OpenG has had to discuss but I'm bringing it up anyway.  There are improvements to LabVIEW that could make OpenG better, but OpenG likely wants to keep support for older versions of LabVIEW.  One such improvement is the ability to Inline VIs.  I think that many OpenG VIs should be inlined, this would make them more like primatives where they are reentrant, and at compile time will be inlined into the calling VI reducing the overhead in calling a sub VI.

 

The issue is that Inlineing was added to LabVIEW in 2010, and I believe the minimum version OpenG supports with the newest release is 2009.  OpenG dropped support in the newest build of packages, for 8.6 and older, over 2 years ago.

 

Thoughts?  Objections?  Obviously OpenG will still support older versions of LabVIEW (OpenG version 2.0 goes back to LabVIEW 6.0) this will just mean that any new features/bug fixes would only be applied to LabVIEW 2010 and newer.

[Tim_S]

As a note for making inline VIs... I've been building plugins using objects in packed libraries. Object properties that are set to inline have thrown packed-library build errors. I don't believe I have any other VIs that have been set to inline when performing the builds.

[Jim Kring]

I think it could make sense for OpenG to start moving to 2010, at least, for active development.  This won't negatively impact people using older versions of OpenG, it just means that they won't be able to install newer versions of OpenG into older versions of LabVIEW.  I think the benefits of moving forward outweigh the benefits of staying on older versions of LabVIEW.

 

Also, it might make sense to change the version of OpenG Libraries to 2010 for those built in 2010 and then create a 2009 branch if any improvements need to also added to the 2009 branch.

[ShaunR]

 I wonder how much active development still goes on in 2009?

I do all my development in 2009 still (although I have all the versions).

[Phillip Brooks]

LabVIEW 8.6 here; a change from LV2009 doesn't affect me... 

[hooovahh]

Thinking about a lot of my use cases though, very little of the OpenG stuff is called in tight/fast loops, so I wonder how much inlining would help. These days I tend to just let the compiler get on with its job and not worry too much about incremental performance gains.

I don't have a lot of tight/fast loops running using OpenG code but I do call OpenG code quite often (Arrays, File I/O, Application Control, LabVIEW Data, String, Time), and inlineing a VI is a quick and simple way to get some extra performance (little or not).  It's not a magic bullet by any means but I made a point when working on our internal reuse library to inline VIs that can be inlined.  There was also a tool NI made for 2012 that measured performance and detected when VIs may benefit from an inlineing operation.

[hooovahh]

If the VI is not being called often is there any point in inlining?

If a VI is being called once, it can benefit from inlineing (assuming it can be inlined and be made reentrant without a functional change)

 

I know in other languages you can force functions to be inlined but I thought it was generally considered to not be a good choice for a human to make most of the time, I think the compiler has far better judgement on which things should be inlined etc.

Maybe that's why I am inlineing so much, I am not familiar with what inlining means in other languages.  Is it just taking text files and basically inserting them into one big file?  If you had 3000 text files (like 3000 vis) would a text based language have a difficulty time using it?

 

 

 

EDIT: The link I posted to earlier mentions this.

Inlining subVIs is most useful for small subVIs, subVIs within a loop, subVIs with unwired outputs, or subVIs you call only once. 

Many OpenG VIs are small subVIs, that could be called within a loop, likely has unwired outputs, and you may call it once.

Edited September 13, 2013 by hooovahh

[Thoric]

Inlining also has the advantage of removing redundant code from the subVI if not required for that particular call (Look for "DFIR Decompositions" in this white paper). The obvious advantage here is not performance, but code size reduction.

[hooovahh]

This crossed my mind again recently so I figured, why not make a VI that makes OpenG VIs inlined?  So attached is just that.  Don't get me wrong it doesn't inline all VIs that'd be crazy.  So what I did was opened each OpenG VI, then look at what VIs can, and can't be inlined, and if they are inlined do they have uninitialized shift registers?  If so then they should likely have the Preallocate for reentrant clones, instead of Shared.  

 

I also modify all OpenG VIs to turn off debugging, and automatic error handling.  In the zip is also a VI I used to verify find all broken OpenG VIs.  This can be used to see if any new broken VIs are made, after making these inlined changes.  For my OpenG setup there are 4 broken VIs that are supposed to be broken, and after running my Modify OpenG VIs.vi I still only have those 4.  I don't know if there are other unintended changes but I haven't seen any yet.  If you use this and find any issues please mention it.

 

Opening each OpenG VI and looking for what can and can't be inlined I noticed that many of the ones that can't be inlined, are due to using local variables, where a constant (or type def constant) would work for getting the type.  I also saw some instances of using the expression node when native math could be used.  And I saw a few times where the conditional disable structure could be used instead of a property node.  Even so all of the array functions can be inlined.

 

If you do use this I recommend backing up your OpenG library, in case something goes wrong.  Or you could just uninstall/reinstall with VIPM I guess.

Modify OpenG VIs For Inline.zip

[hooovahh]

Found a bug, Current VIs Parents Ref__ogtk.vi, and Current VIs Reference__ogtk.vi should not be inlined.  They are index 5 and 6 on the VIs to Modify array and to fix it just turn off Inline for these VIs.  They can still be Shared Reentrant.