OpenG Variant Configuration file library

[Rolf Kalbermatter]

A colleague recently tried to use the OpenG Variant Configuration File Library and found that the loading and saving of more complex structures was pretty slow. A little debugging quickly showed the culprit which is in the way the recursion in that library is resolved by opening a VI reference to itself to call the VI recursively. In LabVIEW 2012 and later the solution to this problem is pretty quick and painless: Just replace the Open VI Reference, Call VI by Reference and Close VI Reference by the actual VI itself. Works like a charm and loading and saving times are then pretty much in par with explicitly programmed VIs using the normal INI file routines (cutting down from 50 seconds to about 500ms for a configuration containing several hundred clustered items).

Now I was wondering if there is anyone who would think that updating this library to be LabVIEW 2012 and later would be a problem?

Edited November 4, 2016 by rolfk

[Neil Pate]

Rolf, sounds like a great idea. I love those VIs but yes they can be on the slow side.

I would happily accept the trade-off of >= LV2012.

[drjdpowell]

Does it require 2012?   I thought recursion worked well before that.

[Rolf Kalbermatter]

2 minutes ago, drjdpowell said:

Does it require 2012?   I thought recursion worked well before that.

Well recursion worked before but only if you opened a reference to the VI explicitedly. Since LabVIEW 2012 you can place a reentrant VI directly into its own diagram.

Edited November 4, 2016 by rolfk

[drjdpowell]

But I have direct recursion, not via VI Server, in packages in 2011 (example: Shortcut Menu from Cluster), and, at least in LVOOP classes, I had recursive calls in LabVIEW 8.6.  OpenG uses VI Server because it was written well before that.

[drjdpowell]

Google suggests 8.5 for recursion with Dynamic Dispatch VIs and 2009 for any VI.

[drjdpowell]

2009 is what OpenG is currently in, I think, so recursion should work.

[hooovahh]

Wow this is a fantastic discovery.  I always knew the OpenG config functions were really slow for large structures but always blamed the NI INI config functions that had to be called so many times.  In the past I've switched over to using the MGI Read/Write Anything code (modifying it a bit for my needs) but I'll look into the improved OpenG solution in the future.

If someone does take on the updating of this package and code, they also may want to use some of the newer LabVIEW features that can improve performance, like inlining, and conditional or concatenating array tunnels.

[Rolf Kalbermatter]

32 minutes ago, drjdpowell said:

Google suggests 8.5 for recursion with Dynamic Dispatch VIs and 2009 for any VI.

Right! I did check and when using shared reentrant clone VIs, then it also works in LabVIEW 2009. In my initial tests I did use the default preallcoated reentrancy of those VIs and that of course can't work as LabVIEW would then have to preallocate an indefinite amount of clones due to recursion and that would for sure crash! 

So LabVIEW 2009 it will stay!