Jump to content

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


Recommended Posts

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:

post-17-0-93645900-1315676185_thumb.png

  • Like 2
Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

Link to post
Share on other sites

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:

post-10325-0-80853200-1316102751_thumb.p

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

post-10325-0-32467100-1316102754_thumb.p

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.

  • Like 1
Link to post
Share on other sites

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!!!)

Link to post
Share on other sites
  • 4 years later...
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.

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 Jim Kring
      [Update: NI Bug 974336]
      There seems to be a bug in the coercion of data to variant when a cluster contains a single element that is a variant. (original post here).
      Note: This bug appears to be very old, going as far back as LV2012. This has been reported to NI in the LV2020 Beta forum. I don't have a Bug ID / CAR yet.
      Coerce to Variant Fail (LV2019).vi


       
      Note that adding another element to the outer cluster causes the problem to go away.


    • By Bas de Jong
      Hello, I'm trying to display an animated GIF on the front panel. This gif should be loaded programmatically based on some user event. My google search led me to use the OpenG Read GIF File (Animated)__ogtk.vi file. However, loading a GIF is extremely slow. It takes almost 20 seconds to execute the vi when I load the attached GIF (I found randomly on the internet). Is this normal? And if so, is there a way to load a gif faster? Because I need to load several and I cannot afford to load maybe 2 minutes only for the gifs.

    • By ShaunR
      Maybe others have seen this but I only became aware of it recently so I apologise if there is already a CAR for it.
      The following demonstrates a difference in behaviour between LabVIEW 2017 and previous versions (back as far as 2009, maybe further).
      The VI registers an event when it starts (in the timeout case) and generates a user event when the Increment button is pressed.
      The expected behaviour is that the counter will increment by one every time the button is pressed. This is the case for LabVIEW versions prior to 2017. In 2017, the user event is never fired, nor is there an error emitted by the generate user event.
      To get the VI to operate as expected in 2017; change the event refnum tunnel to a shift register. This seems to indicate that the refnum prototype is stomping on the dynamically allocated reference whereas in previous LabVIEW versions it would not. Note also, that when using the shift register, the cases do not need to be "wired through" as would be expected with similar functionality in a normal case statement.
      evnt.vi
    • By A Scottish moose
      Hey everyone,
       
      I am working on a backup function for a test executive.  The backup uses the 'class to XML' vi to create an XML string and then save it to a file to be reloaded later. All of my test specific information lives in the class (or one of it's children).  I like this functionality because it makes backup and reload brainless.  It just works.... until now... I've got a test class for my current tester that's grown rather large.  Everything works fine, until the tester loads some waveform data into either of the waveform arrays.  Without data in this field the class reloads just fine, otherwise if fails and says the XML is corrupted.
       
      As you can see in my backup vi I have built in a work around that flattens the waveform arrays to strings, drops them back into the class private data, deletes the waveform arrays and then writes the class.  This works! Much to my surprise both waveform data and the rest of the class data are written to file and reloaded without error.  
       
      Does anyone have any knowledge or experience with this? 
       
      Cheers,
       
      Tim


    • By fennectp
      Hi all,
       
      I've got a customer that wants to zip/unzip files on their cRIO-9035, so I had them playing with the OpenG Zip tools to see if it would fit their needs. Although they've found that they can zip files on their cRIO just fine, they find that they get disconnected from their RT target and the shell shows the following error message:
      LabVIEW caught a fatal signal 15.0 - Recieved SIGSEGV Reason: address not mapped to object Attempt to reference address: 0x0x10000000 stdin: is not a tty  
      The zip file they're testing with includes two simple .txt files with short strings in them ("booya" and "booya2"). This file unzips just fine on the host PC with the "ZLIB Extract All Files To Dir" VI, but when copied over to the cRIO and unzipped via the same VI, it only unzips the first text file and the resulting file doesn't have any text in it.
      I've attached a copy of the project and the zip file I used to reproduce this behavior using a cRIO-9033 that I had on hand. (The only thing I can't provide is the cRIO >_<)
      Could anybody tell me what I'm doing wrong? Any suggestions as to what other workarounds I could take to zip/unzip files on a LinuxRT target would also be very much appreciated!
       
      Regards,

      Tamon
      Unzip on cRIO-9033.zip
×
×
  • Create New...

Important Information

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