Jump to content

LabVIEW 2019 Map data type


Recommended Posts

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.

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

Link to post
Share on other sites
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

Link to post
Share on other sites

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 by smithd
  • Thanks 1
Link to post
Share on other sites

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.

Link to post
Share on other sites
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 by JKSH
Clarification
Link to post
Share on other sites
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

Link to post
Share on other sites
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:

Screen Shot 2020-05-09 at 3.04.17 AM.png

Watch this presentation by @altenbach : 

 

Link to post
Share on other sites
3 hours ago, Michael Aivaliotis said:

A for loop will do it easily:

Screen Shot 2020-05-09 at 3.04.17 AM.png

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.

Link to post
Share on other sites

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

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.

×
×
  • Create New...

Important Information

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