Leaderboard

You can extract the labels from the type descriptor, once you know where to find them in the array. I added support for it in this open source DataManipulation library. Check out the OpenDescriptor palette. You can install the latest release (1.1.0.5) from here: https://github.com/LabVIEW-Open-Source/DataManipulation/releases/tag/1.1.0.5 (download VIP file and install with VIPM). Once installed, you'll find the "List Element Names" method under Addons>DataManipulation>OpenDescriptor palette. (It can list enums and cluster elements as well, although those are natively supported under the Variant Utilities palette.)

So I got very excited when I saw that LabVIEW 2019 has a new native map type (aka hash array, associative array, dictionary) and so decided to have a play and see how it compared to my home-rolled LVOOP has array that uses variant attributes and I must admit that I'm slightly underwhelmed.... I've now benchmarked the 2019 native map class and a simple variant attribute by creating maps of 1 million elements of randomly generated 8 byte keys and then reading back 10,000 randomly selected elements and fairly consistently the native map is about an extra 50% slower than the variant attribute for both read and write operations. I'll admit my benchmark code is quite naive, but it's still a little disappointing that there is quite this performance hit.... Can any of the NI folks here comment on the performance - is it just that in fact variant attributes are blazingly fast? I know I shouldn't be churlish and it's really great that 2019 has so many new features and a native map and set type have been long overdue... Edit: and yes I've spotted that the variant type conversion was wired wrong and I should have been generating an array of 10000 I32 not error clusters - but no it doesn't make a significant difference....

No problem, I just want to make sure people know the difference between "Darren the G programmer says _____" and "Darren the NI employee says _____". In my "Don't Wait for LabVIEW R&D... Implement Your Own LabVIEW Features!" presentation, after I clarify that I'm presenting my personal opinion and not an official NI position, I contraindicate XControls because of numerous stability issues I've seen with them in large applications over the years. You can see my slides and watch a recording of the presentation here: http://bit.ly/dnattlvhooks

I would always recommend wiring up the output of the read nodes to an array indicator (outside the sequence so that it has no effect on timing). Compiler optimisations can do weird things when you're not actually wiring up certain outputs. For example, you're not using the data output of the variant but you are of the map. Not saying it explains the differences, but I've seen things like that wildly affect performance in the past. I would look at the code, but I'm currently trying to get 2019 installed in a VM.

I'm pretty sure that you've built your block diagram incorrectly. Just do it right and it will work fine. (Since you didn't provide any code, I can't be more specific than that.)