bug Recursive OpenG VIs should use native recursion (if performance benefit)

[Jim Kring]

There are some OpenG VIs, like the Variant Configuration File IO VIs, that use the legacy form of recursion (VI Server Call By Reference to self), which is (I believe) much less efficient than using the native recursion feature introduced in LabVIEW 2009. I would recommend changing all VIs that use legacy recursion to use native recursion, provided that a performance improvement would be gained.

Here's a screenshot, showing what I mean:

[Ton Plomp]

Yes, I am in favour of that.

Ton

[GregSands]

Perhaps it would be a good opportunity to evaluate whether a non-recursive implementation would be better (i.e. simpler, faster, clearer, lower memory etc). For example, Write Key (Variant) could use a queue rather than a recursive call - what are the pros and cons of doing it that way? For a single Key (which is not a Cluster or Array) I imagine there would be a significant cost in creating the queue, but that is quickly traded off against the cost of setting up a recursive call. Perhaps the queue only gets created inside the Cluster/Array case.

But if recursion is retained, then the native approach is certainly cleaner.

[Aristos Queue]

Jim Kring wrote:

> which is (I believe) much less efficient

I can confirm your belief. The native recursion is better performance.

Greg Sands wrote:

> Perhaps it would be a good opportunity to evaluate

> whether a non-recursive implementation would be better

All recursive algorithms can be re-written iteratively. You would be evaluating this trade-off on a case-by-case basis. As far as readability is concerned, in general, the more parameters that the recursive function has, the more the recursive solution is better than the iterative. For something with very few input parameters, the iterative is often easier to understand.

The performance tradeoff is more clear cut in LabVIEW -- the iterative solution will generally out perform the recursive one. The LabVIEW compiler's dataspace call structure is different from the stack-based approach of most compilers. Our structure allows for better cooperative multitasking, but it does mean a relatively high overhead for recursive calls since we have to actually allocate heap space instead of just moving a stack pointer. However, I'm sure there is a level of complexity where the recursive solution wins, but it is probably fairly high up.

[Darin]

I once benchmarked a variety of VIs to implement the simple Array Max/Min. Obviously the built-in function reigns supreme (otherwise somebody is not doing their job). G equivalents were about 50%-200% slower than the native function depending on the sophistication of the algorithm. An implementation with native recursion was about 30 times slower than the primitive, the VI server equivalent was about 30 times slower than native recursion (when it worked) and crashed for arrays larger than 1000 elements.

My own opinion is that the beauty, simplicity and overall coolness justifies [native] recursion in many instances. Especially true for many parsing applications since it seamlessly handles nesting and very few instances require more than a few layers. VI Server recursion should not be used, ever. What you gain in readability by going to recursion is instantly lost, so you are usually much better off implementing the iterative solution.

[jgcode]

There are some OpenG VIs, like the Variant Configuration File IO VIs, that use the legacy form of recursion (VI Server Call By Reference to self), which is (I believe) much less efficient than using the native recursion feature introduced in LabVIEW 2009.

I quickly wrote a tool using Traverse Refs (thanks D!) to scan the OpenG Library to discover CallBeRef node and if Re-entrant.

Here are the results:

Please comment if you think tool may have missed any VIs etc...

I can add these to DB to be fixed based on outcomes of this performance benefits discussion.

Check OpenG Library for Recursive VIs.vi

Code in LabVIEW 2009.

[Jim Kring]

I quickly wrote a tool using Traverse Refs (thanks D!) to scan the OpenG Library to discover CallBeRef node and if Re-entrant.

Here are the results:

Please comment if you think tool may have missed any VIs etc...

I can add these to DB to be fixed based on outcomes of this performance benefits discussion.

Code in LabVIEW 2009.

Great! That's probably all of them.

(Also, Darren Rocks!!!)

[Darren]

Thanks, guys.

JG: I noticed in your VI you are checking the VI Type to determine whether or not you should traverse. A more robust way to determine if a VI has a block diagram is to use this VI:

vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Has Diagram.vi

Despite its name/location, this VI does ship with LabVIEW core...use it whenever trying to figure out if a VI has a diagram. There is also a VIAnUtil Has Panel.vi in the same LLB.

[jgcode]

(Also, Darren Rocks!!!)

I concur!

If anyone is interested here is Darren's suggestion implemented.

(It doesn't change functionality) but I am also one to try/learn new things/VIs

Thanks again D!

Check OpenG Library for Recursive VIs.vi

Code is in LabVIEW 2009

[jgcode]

You can track these bugs here:

• ID: 3411108 - Variant Configuration Library
  
• ID: 3411109 - LabVIEW Data Library
  

[ArjanWiskerke]

I found "VI properties = reentrant execution". Has to be non-reentrant execution to allow for recurrency. Is that OK for these VI's?

[Aristos Queue]

1 hour ago, ArjanWiskerke said:

I found "VI properties = reentrant execution". Has to be non-reentrant execution to allow for recurrency. Is that OK for these VI's?

You have that backward. It has to be reentrant to allow for recursion. If the VI is non-reentrant, it will be broken when you drop a subVI call to itself on its own block diagram.