LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Python Dictionary ported to LabVIEW


@crabstew wrote:

On average, inserts and gets are much faster than variant attributes, relabels are orders of magnitude faster and deletes are a tad slower.

1000 elements

 

Try it out and see if you can squeeze any more performance out of it. I'm not super familiar with the intricacies of the LabVIEW compiler so I'm sure there is something I've overlooked performance-wise but it was pretty fun nonetheless and I'm quite happy with the results.


Your 1st timing includes the time to create the arrays, if you wire the created array through the 1st frame time will change considerably.

Also, it seems Variants as variant attributes are slow. If you set the Integers as data instead of the converted variant (fix the wire to the 1st frame) this is what happens:

Hash.PNG

The Relabel is much slower on the variant attribute, the other operations noticably faster!

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 11 of 20
(1,211 Views)

Hash 2.PNG

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 12 of 20
(1,209 Views)

What LabVIEW version are you running 

 

0 Kudos
Message 13 of 20
(1,194 Views)

I also ran 2017, didn't compile it though. Those Variant Attributes are pretty well optimized. You can 'hash' Variant attributes so you don't have all in one variant, that should be interesting when the lists start to grow (>10k?)

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 14 of 20
(1,181 Views)

Just tested at home, better computer than the work one. Parallellized all loops (except the comparison ones since they couldn't be. Comparison between IDE and compiled result.

Variant hash, IDE on topVariant hash, IDE on top

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 15 of 20
(1,177 Views)

Can you post your test.vi?

0 Kudos
Message 16 of 20
(1,168 Views)

Not right now, i went on to try and 'hash' the variant by using an array of variants instead of 1, that didn't turn out good. 🙂

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 17 of 20
(1,146 Views)

I found a copy. I noticed a strange effect of Variants in the Get Library case which i've worked around and commented in the code.

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 18 of 20
(1,144 Views)

Looking closer at the test code (both the original and the modified) I think there is a lot to improve....Building arrays of the variant (and dictionary references) for each run instead of operating on the same all through the run is a bit odd in my mind for example. The key names are not guaranteed to be unique either, I typically get half a percent collisions...(50 per 10 000 keys).The modified version introduces another variable - parallelism. I would say that adds  a somewhat irrelevant complexity (unless of course you would access it like that in the actual application), when what we really want with the repeated runs is to just average out noise in the numbers.

 

Rebuilding the test code to just repeat the whole train of operations instead on each run, and work on a single variant/dictionary ref, the results are more in line with the good results I got when using the hash map in a realistic scenario (based on storing doubles only) on a slower target (cRIO-9030).  I find the hash table to be 2x times faster than the Variant on writes on my PC, but 3 times faster on a cRIO-9030 (Linux RT). The inserts and reads are pretty much identical on the PC, but reads are 30% faster on the Linux RT target. The hash table is extremely sluggish when it comes to deletes though, as it is right now.

0 Kudos
Message 19 of 20
(1,138 Views)

The point of the parallellism test is to see how fast it can go and how well it scales (it seems Variant scale slightly better). I'd say that's interesting for real world implementation, but first and foremost you should optimize the individual parts.

/Y

G# - Award winning reference based OOP for LV, for free! ADDQ VIPM Now on GitHub
"Only dead fish swim downstream" - "My life for Kudos!" - "Dumb people repeat old mistakes - smart ones create new ones."
Certified-LabVIEW-Developer
0 Kudos
Message 20 of 20
(1,133 Views)