Hash table equivalent

[mike5]

Is there an equivalent of a hash table in LabView?

Thanks in advance, Miha

[jzoller]

Not that I've seen.

You can build your own hash table system with arrays for storage. The actual hashing function is up to you, as are features like chaining and collision resolution.

You can also implement dictionaries, either with parallel arrays, or using the Variant and Variant Attribute types (which have an underlying red-black tree for speed).

Joe Z.

[gb119]

Is there an equivalent of a hash table in LabView?

Not that I've seen.

You can build your own hash table system with arrays for storage. The actual hashing function is up to you, as are features like chaining and collision resolution.

You can also implement dictionaries, either with parallel arrays, or using the Variant and Variant Attribute types (which have an underlying red-black tree for speed).

There was a (long) thread on various hash (or map or dictionary) implementations started by Aristo Queue when he introduced an implementation using classes - various implementations were tried and benchmarked - this seems to be the relevant page in thr topic.

At the ime variant attribute seemed like it was the best (cespite those that should know about the internals of LabVIEW being surprised). I know AQ noted that his map with classes suffered from some specific bugs deep in the memory management interneals - I'm less clear if the performance has been fixed in 2009...

[jdunham]

There was a (long) thread on various hash (or map or dictionary) implementations started by Aristo Queue when he introduced an implementation using classes - various implementations were tried and benchmarked - this seems to be the relevant page in thr topic.

At the ime variant attribute seemed like it was the best (cespite those that should know about the internals of LabVIEW being surprised). I know AQ noted that his map with classes suffered from some specific bugs deep in the memory management interneals - I'm less clear if the performance has been fixed in 2009...

Last time I looked into this about six months ago, the bug which had destroyed performance in the lvclass implementation had been fixed as of LV2009, but variant attributes still blew away the lvclass implementation in terms of performance, so we are still using that for hash tables. You'll want to keep your variant (which doesn't need to contain any data itself) in a functional global (aka LV2 global). You could also keep the variant in a data value reference or in a single-element queue to protect its integrity.

[mike5]

I don't know whether to ask this here or on the other thread, but are there any drawbacks about using Variant Attributes on real-time targets? Besides memory... And on that note, is there a better way of getting the number of the elements in the Variant than producing names/values arrays just to get the length?

Miha

[smenjoulet]

I don't know whether to ask this here or on the other thread, but are there any drawbacks about using Variant Attributes on real-time targets? Besides memory... And on that note, is there a better way of getting the number of the elements in the Variant than producing names/values arrays just to get the length?

Miha

Can't answer the RT part of the question.

For your second question though, you could store the size of the table in the variant itself as it is not used for anything else in this scenario. Just remember to update the count whenever you add or remove a key/value pair.

-Scott

[mike5]

Can't answer the RT part of the question.

For your second question though, you could store the size of the table in the variant itself as it is not used for anything else in this scenario. Just remember to update the count whenever you add or remove a key/value pair.

-Scott

What an excellent suggestion Thanks.

Miha