What is the impact of using a variant data type on performance, speed memory demands etc?

[Ben]

This is another one of my "lets get this settled once and for all" threads.

I have avoided variant data types whenever possible to keep the performance of my apps up. From some observatsions i have made over the years, I am of the opinion that;

1) In-place operations can not be carried out on variants.

2) Passing a variant to a sub-VI (regardless of the terminal on the icon connector) are always copied.

I would like confirmation or correction of the above so we know more about this animal we call LabVIEW.

Thank you,

Ben

[Ben · Accepted solution]

---

@Ben wrote:

This is another one of my "lets get this settled once and for all" threads.

I have avoided variant data types whenever possible to keep the performance of my apps up. From some observatsions i have made over the years, I am of the opinion that;

1) In-place operations can not be carried out on variants.

2) Passing a variant to a sub-VI (regardless of the terminal on the icon connector) are always copied.

I would like confirmation or correction of the above so we know more about this animal we call LabVIEW.

Thank you,

Ben

---

I did verify I can pass a variant to a sub-VI with a copy but it is still impossible to do anything (scaling limit checks etc) with a variant without first copying it to a new buffer when converting "from variant".

So,

 For large data sets, Variants are a bad idea.

Ben

[F._Schubert]

Ben, can you be a bit more detailed on your observations (pictures?). If some new user is asking the same question, they won't be able to follow you.

Also my own question on this, I assume that large data sets where 2D-Arrays of double passed as Variants. What is about passing DBL-Variants in an 2D-array? I guess that they will perform bad because you have an array with elements that are of variable length in this case and you have all the variant overhead a multiple of times.

Felix

[Jarrod_S.]

A couple notes:

1. You can use the To/From Variant nodes for the Inplace Element Structure to operate inplace on the contained variant data. This should work just fine even if you have a big 2D array contained.

2. Variants are incredibly useful when you use them for Variant Attributes, rather than just storing data. The Variant Attribute implementation uses a binary tree to store the key value pairs, which provides quick insertion and lookup.

3. I don't work on the internals of LV, but I see no reason whatsoever that passing a variant into a subVI would always necessitate a copy. I could be wrong, but that sounds very odd to me.

However, I have generally started trending towards using flattened strings. Flattened strings are generally more efficient memory-wise, because they don't contain all the type descriptor information, just the raw data. (I think there's some exception when flattening LV Classes.) Variants always store the type descriptor, so even an empty variant can take up a bit of memory.

Variants received a big performance boost from 7.x to 8.x. They used to have a bad reputation, but I wouldn't be afraid to use them where applicable. I personally don't see a lot of benefits over flattened strings, though, except in the case of tools like the OpenG Variant INI files, which can dynamically parse out and construct variant types.

[Intaris]

A little bit of thread resurrection here.....

Related question:  Does "Variant to Data" make a data copy?  I have recently proposed using the IPE for avoiding a data copy (Our variant can eb a few MB in size) but am now unsure as to whether the "Variant to Data" even produces a copy or not.  The buffer allocation always shows a buffer allocation, but this can be due simply to the case where the converstion fails.....

Shane

[nathand]

The most detailed information I've seen about variants is in this LAVA thread. Best I can tell, no copy is required if you're going directly from data to variant and then back again later. There's a buffer allocation because the variant structure has a small amount of overhead.