Correct way of using the Variant Get/Replace In-Place Element Structure function?

[Mads]

The new IPE-function "Variant Attribute Get/Replace" introduced in 2016 can dramatically improve the performance of accessing variant attributes, but it seems a bit unclear exactly what the "correct" way of using the replace is.

The example that ships with LabVIEW "Modify or Add Variant Attribute.vi" covers a manipulation case where you need to read the current value of the attribute, manipulate it and then replace it with the manipulated one. Here is a screenshot of this bit:

The example does not cover cases where you do not have a need for the previous value, but just want to replace it. You can then either replace it with an attribute of the same data type, or with a different data type...

To illustrate the first of these it might look like this:

There are two questions that come to mind here:

1) Is it OK to skip the whole variant to data IPE bit as I've done here...that seems locial as I do not need the previous value anyway.

2) I have skipped the case to handle whether the attribute was found or not (the IPE help states that if the attribute is not found the whole oepration is ignored anyway...so why care about the if-case unless I have some additional handling to take care of then?

3) Why does the code break? 

The broken state is caused by the fact that the output of the "Get attribute" part of the IPE in this case has not been wired to anything. The IPE has the rather strange requirement that it requires you to wire some outputs...not just inputs. OK.

But hey, it does not seemingly matter *what* we wire it to. We can for example get back to running code just by wiring it to the side of the structure, like this:

Now everything seems to work fine, *and* the performance gain has been maintained.

I've run a few tests to figure out if variations on the theme/alternatives highlighted in the questions above point out a "correct" or "optimal" way of coding this, but I cannot say I've found an answer yet. *Is* there a "correct" or rather "best" way of doing this? Perhaps the compiler is just too good at "fixing" non-optimal coding, but might fail to do so in some cases?

If the new attribute has a different data type than the previous one.:Do we still get an increase in the performance then, and/or are does it have the same answer as for the scenario with the same data type? I have not tested that part out yet.

It would be great to get some insight into the details here (or to know that no such insight is needed :-) ).

[Sam_Sharp]

The in-place element is designed for read-modify-write operations as the idea of it is to be a memory efficient way of replacing/modifying some data in a memory space that already exists.

I do agree with you though - I don't think it should cause a broken run arrow if you don't wire out the original value.

If you are just updating a value and don't care for the previous value, just re-set it using the primitive as it does on the right-hand side of the diagram?

[Mads]

"If you are just updating a value and don't care for the previous value, just re-set it using the primitive as it does on the right-hand side of the diagram?"

If you are thinking about the right-most bit of the first picture where the example uses the non-IPE set attribute primitive to create a new attribute (?) then that would not produce the performance gain introduced with the IPE (at least my tests indicate that I get an improvement). I can use the IPE as in the third picture (with the output wired to the side of the structure to avoid the broken arrow) for that, that works fine.

[Sam_Sharp]

Do you actually get better performance when in your 3rd picture (with the variant wired to the border) than if you just use 'set variant attribute'? If so, I'd be tempted to say that it was unexpected behaviour (and therefore could be raised as a CAR) and it should be made to allow the terminal to be unwired.

My understanding is that the IPE allows you to retrieve the variant attribute without creating a copy in memory (which would require new allocations which take time) so if you're creating a variant attribute, you'd still need to allocate the memory for the variant attribute so I wouldn't expect much performance difference. The improvement in performance is when you read-modify-write as it saves that memory allocation when you retrieve the attribute. (But I haven't tested any of this, so I'd be interested to see if there is a performance difference)

[Mads]

"Do you actually get better performance when in your 3rd picture (with the variant wired to the border) than if you just use 'set variant attribute'? "

Yes the performance looks much better, at least with the scenarios I have tested so far.

"My understanding is that the IPE allows you to retrieve the variant attribute without creating a copy in memory (which would require new allocations which take time) so if you're creating a variant attribute, you'd still need to allocate the memory for the variant attribute so I wouldn't expect much performance difference."

I'm not creating the attribute within the IPE, there I'm only replacing its value if it exists (you could say that it is a modification that happens to not have anything left of the original value   ). 

But this is partially why I posted the question; I was hoping that someone with behind the scenes knowledge or lots of experience with the feature already..(a bit early) could shed more light on what to expect when using the function.

[Sam_Sharp]

Oh - I've just remembered/thought - I think this is one of places where you might use the 'swap values' primitive:

(shown here with the index/replace - I don't have LV 2016 yet)

[Hooovahh]

Awesome idea with the swap, although maybe it isn't really needed and performance would be better just wiring it to a terminal that isn't used.

@mads

Can you share the performance checking code you have?  I'm sure it isn't too complicated but I'd like to know how these different options stack up because I suspect I'll be using the Variant Attributes this way more often then the read-modify-write.

EDIT:  Oh the swap values might not work as well since the swap needs the data type to be the same for both values, which means adding a To Variant to whatever you are writing.

[Hooovahh]

I just made my own speed test and you can tell me how I did it wrong.  I added a few other cases because I also like the idea of making the attribute if it doesn't exist, but that of course makes it slower.  It still seems about twice as fast or more as the primitives regardless.

[Mads]

Hooovahh - two comments about your test code:

a) you have the swap elements function set to NOT swap the values...(? input set to false, making it a no-op kind of...). The difference between "IPE" and "IPE With Swap" seems to be exaggerated by this.

b) For some reason "IPE With Create and Swap" is considerably slower than "IPE With Create", even though "IPE" and "IPE With Swap" are pretty much identical (once the swap has been set to true, as mentioned in item a above). I have not figured out that one yet...The swap seems a tad faster than the wire to structure only version...so why the jump when there is a create too, compared to a create in the wire to structure version...is a bit of a mystery.

Anway, the tests confirm what I have seen...so I guess the only thing we do not (but NI do?) know is why the feature requires the previous value to be wired to *anything*...perhaps that is just a (relatively harmless) bug?

[Sam_Sharp]

Have you raised a ticket with NI? If you do, post the CAR number here so we can follow it. 🙂