LabVIEW 2019 Map data type

[crossrulz]

No.  It is more like they just use the same library on the back end.  But a Map is not going through a conversion to a variant first.

[Aristos Queue]

On 5/5/2020 at 6:36 PM, JKSH said:

Does that mean a LabVIEW map converts the data to/from variants behind the scenes, even though the datatype is fixed at edit-time?

No. That's not what I said at all. 

[mcduff]

On 5/5/2020 at 8:09 AM, Aristos Queue said:

Nope. Variant attributes and maps use the same — identical — underlying data structure. For reasons I don’t grasp, the C++ compiler adds a couple extra instructions in the maps case only when the keys are strings that aren’t in the variant attributes. Still, the conversion time to/from variant for the value tends to dominate for any real application. 

Please correct my misunderstanding, the biggest difference between Maps and Variant attributes are

Maps: Keys can be anything (all keys the same type), but all "attributes" need to be the same type.

Variant: Keys need to be strings, but "attributes" can be different types.

The structure seems similar, although slightly different.

mcduff

[smithd]

A better way of looking at it might be that a variant is a specific data type.

so if we assume c++ has some map<keyType, valueType> under the hood, the new labview map type exposes this directly and lets keyType and valueType be any labview type.

the variant attribute system was specifically map<string, variant>. The api added some sugar on top so that if you specified a type, it performed variantToData(map.read(myStringKey), myDataType)...but it was still a map<string, variant>. If the content of your variant is a big array, this could potentially cause performance issues because of that variantToData. Vs 2019 where your map type might be map<string, lvArrayHandle> which doesnt need any of the weird memory allocation that happens if you call variantToData(myArrayInsideOfAVariant, dblArrayType).

I dont know if this is precisely accurate, but thats what my general understanding was. 

Edited May 7, 2020 by smithd

[Michael Aivaliotis]

My understanding is that Maps are the same as variant attributes. Except with maps, obviously you don't have the overhead of VariantToData or DataToVariant, when inserting data or looking up data. That can be a huge overhead in some cases. Plus you need support code to prevent variant conversion errors when using the wrong typecast.

Variant attributes are slightly more powerful than Maps because you can insert any type. However, one could argue that this is a characteristic that leads to messy designs. The same variant wire could contain mixed values types within it. Each with its' own type conversion VIs. I think if you've been using variant attributes and it works for you, I don't think you need to rewrite everything. But they definitely need to be considered in new designs. Because you don't have the overhead of creating all the glue VIs for the data conversion, they are frictionless to use and start using out of the box.

[JKSH]

On 5/7/2020 at 9:41 AM, Aristos Queue said:

No. That's not what I said at all. 

My apologies. I just wanted to make 101% sure that "Variant attributes and maps use the same — identical — underlying data structure" does not mean "maps store data as variants just like variant attributes".

I'm now 101% sure; thanks for replying.

Edited May 9, 2020 by JKSH
Clarification

[Michael Aivaliotis]

20 hours ago, JKSH said:

I'm now 101% sure; thanks for replying.

Curious, does this change your choice in using them or is it purely academic?

[JKSH]

30 minutes ago, Michael Aivaliotis said:

Curious, does this change your choice in using them or is it purely academic?

It makes me relieved that my fears were unfounded.

In the beginning, I was under the impression that LV 2019 maps were like C++ maps as @smithd described, where the value type is chosen by the programmer and fixed at edit time, and no variant conversion was involved. All was fine and well.

However, when I read AQ's comment ("Variant attributes and maps use the same — identical — underlying data structure.... the conversion time to/from variant for the value tends to dominate for any real application"), I misunderstood him so an uncertainty crept into my mind. I thought, "Hang on... could it be that LV maps are simply a nice wrapper around the old variant storage structure? That same structure that always stores data as variants? If so, that means maps require variant conversion which makes them less awesome than I originally thought!"

The subsequent replies showed that I had nothing to worry about. Also, if I had thought it through more carefully, it would've been obvious that the LV 2019 map can't possibly be a simple wrapper around variant attributes because the old structure doesn't support non-string keys.

---------------

TL;DR: I misunderstood AQ and didn't think clearly, so I got worried that LV maps had a flaw. The worry was unfounded. Maps remain awesome.

--------------

Anyway, even if maps did require variant conversions, that wouldn't make maps any worse than variant attributes. The map API is a lot cleaner^ than the variant attribute API so maps would've still been the better choice.

Since maps don't require variant conversions, that makes them far more awesome than variant attributes.

 

^One exception: I have to write a bit more code to get the list of map keys, compared to Get Variant Attribute with an unwired "name" input

[Michael Aivaliotis]

38 minutes ago, JKSH said:

^One exception: I have to write a bit more code to get the list of map keys, compared to Get Variant Attribute with an unwired "name" input

The keys can be any type. A for loop will do it easily:

Watch this presentation by @altenbach : 

 

[JKSH]

3 hours ago, Michael Aivaliotis said:

A for loop will do it easily:

That's what I meant by "write a bit more code" It's not a showstopper though, especially since we can put that in a VIM.

Thanks for the video link.

[gb119]

The pother advantage of the Map type over the variant attributes is that it serialises correctly with the Variant to XML string node. Very annoyingly, in LV2019 it's not supported by the NI Variant to JSON node (I don't know if that'#s been corrected in LV2020 - I'm a little nervous about mixing the Community edition for my personal play-time projects with my academic site licensed LV installs for work and playing...).

[Antoine Chalons]

Hello Map lovers

I've just posted an idea on the NI Exchange to suggest an option to have reverse indexing option on a for loop.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Reverse-order-indexing-for-Map-on-for-loop/idi-p/4088548

Edited October 6, 2020 by Antoine Chalons

[Jim Kring]

On 5/9/2020 at 8:02 AM, JKSH said:

That's what I meant by "write a bit more code" It's not a showstopper though, especially since we can put that in a VIM.

Thanks for the video link.

there's a package such VIMs here: https://www.vipm.io/package/vipm_lib_labview_collection_extensions/