Skip to content

Aristos Queue on Inlined VIs and Memory Usage

by Brian on August 23, 2011

Our first guest blog post… we’re excited to have a short write-up from Aristos Queue (known in real life as Stephen Mercer, one of our Senior Software Engineers in LabVIEW R&D).

A rumor has reached my ears. A false rumor about LabVIEW, inlining subVIs and buffer allocations. A rumor in need of quashing.

Several experienced G programmers at NI met to discuss what we had learned at NIWeek. At this meeting, one of our number expressed his excitement about the Inline subVI into calling VIs option (found in the VI Properties dialog). First he talked about the performance improvements. Then he talked about the memory usage improvements. To demonstrate, he turned on Tools >> Profile >> Show Buffer Allocations and showed buffer allocations on a number of subVIs. Then he turned on inlining for those subVIs and refreshed the buffer allocations. We witnessed a miracle: all of the buffer dots disappear on all inlined subVIs. To him, all the extra memory that inlining a subVI might allocate at launch and waste was acceptable since he could eliminate all the jitter from memory allocations while running. Many heads in the room were nodding in excitement; they would all be using inlining heavily on real-time (RT) projects in the future.

I, too, was impressed with this trick at first… but the more I looked at his diagram, the more I realized this had to be a bug. I went to the LabVIEW compiler gurus to confirm my suspicion. Sure enough: the buffer allocation dots just do not draw on inlined subVI nodes although the buffers are still allocated. In one sense, this is minor bug. The VIs still function correctly, nothing is broken in the compiler… this is merely a cosmetic bug that the little black dots aren’t being drawn. In another sense, it is a major bug because of what it teaches our users. Users rely on the dots to do the memory analysis of their VIs; they need our buffer allocation dots to tell them for what LabVIEW is doing, and on RT, those dots show them where jitter is occurring. A feature that eliminates all the dots? That’s solid gold even if it does make the code size bigger!

I hate to be a killjoy. I hate telling you that the vision of no dots on your block diagram is just an illusion. But if I let you wander around in this dream state, you’ll end up bashing your head on something (probably your keyboard as you are trying to debug where the jitter in your RT application is coming from). Therefore, I have to say this: Buffer allocation dots do not draw on inlined subVI nodes. This is a bug in LabVIEW 2010 and 2011. It has been filed to be fixed in a future LabVIEW version. I don’t even have a good workaround for you to ease your transition back to the waking world. The best I can offer is this: Inlining a subVI almost never removes the need for a buffer allocation, so if you look at the buffer allocations with inlining turned off, those buffer allocations are probably still there when you turn inlining on. Do your “hide the dots” work with inlining off, and when you’re satisfied with that, turn inlining on for the performance benefits.

I hope you had a pleasant sleep.

— Aristos Queue

 

From → Programming

6 Comments Leave one →
  1. Jaegen permalink

    Good to know! Thanks AQ/Brian.

  2. Mads permalink

    Nice to know, but why does it allocate those buffers? If the code is in fact inlined, should it not behave as if the code was written on the same diagram? It makes sense that the dots disappear, that’s probably why people do this – and would have done it even if they did not have the buffer allocations feature available.

    This indicates that inlining is done in a way that differs slightly from how people envision it. Could you explain what that difference is?

  3. Thank you Stephen for this blog.

    Mads,

    Search the NI web-site using the search terms “clear as mud” to find an old post by Greg McKaskle talking about the conditions required for the LV compiler to duplicate a buffer or not.

    Reader’s Digest verion of that post:

    “If the terminal is on the root of the diagram and no opeartors that duplicate buffers is attached to the wire (look but no touch) LV will not duplicate the buffer.

    Ben

  4. Aristos Queue responds…

    Inlining code does not change what the code does. Let’s take a simple example: a subVI that takes an integer as input and has a string as an output. There has to be a buffer allocated to hold that string. If the subVI is inlined, space for the string still has to be allocated. If you simply cut and paste the code from the subVI into the caller VI, you would see an allocation somewhere in that code. Getting that inner allocation to be reflected on the terminal of the subVI is important because otherwise it appears that the string is generated without taking up any space. The only time inlining might reduce a buffer allocation is when you have multiple inlined VIs interacting with each other in such a way that LabVIEW decides it can consolidate buffers, but this is not common.

  5. what is the status of this “feature”. has it been fixed in 2012/2013?

  6. Aristos Queue permalink

    No. There is no change in its status in 2012 nor will there be any change in 2013. I have kicked the CAR priority for 2014, but it will be considered along with all the other issues that team is working on.

Leave a Reply

Note: HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

This site uses Akismet to reduce spam. Learn how your comment data is processed.