3 replies to this topic

[klessm1]

I did a quick search of the website but I didn’t see something like this posted so I’d thought I’d post it. It’s probably been done before but I found that it pretty helpful in my current project.

I usually use DVRs whenever I want to use the aggregation pattern (zero or more relationship). Many times though I want to sort or return an object from the array based on an attribute in the object (like name). Since I am using a DVR I found I can quickly make a hash table using variant attributes. I just use the “Name” or other unique value and make the DVR the value. I can then lookup a DVR by name through the variant. It stays really fast because the DVR is just a reference to the data and I am not looping through DVR references and comparing the name or unique value to the value in the object.

Example use:
I can lookup these commands by name or opcode using the variant hash table.

I create the lookup based on name.


I also create the lookup based on opcode


I can then lookup the object very quickly based on name or opcode.

[Aristos Queue]

Yep. It's a good trick. One of those useful tricks to keep in your back pocket.

[0_o]

Instead of using the name which is possibly not unique you can flatten the dvr to string and use it as a unique identifier.
In order to prevent duplicated refs or different refs that point to the same data you can add a dup check while building your lookup:
Before adding a ref iterate over the existing dvrs and try to inset the new dvr and the current dvr from your lookup into an in place structure.
If the two dvrs refer to the same data LV will give you error 1557. Catch it and if it was caught don't add the dvr into the lookup.
Since you might have two different dvrs referring to the same data, searching for a dvr in the array might still require the 1557 error testing and thus reduce the theoretical performance.
Beside that, watch out of the dvr life span. DVRs live as long as the application that created them live. You might get a lookup table with invalid dvrs.
Moreover, you might want to add a privacy mechanism since you don't want everyone to access any dvr. It is true that a dvr can be opened only by vis from the class that it was created from yet I don't want someone to iterate over the dvrs array calling some execute.vi for example if I don't want it to (a use case might be a different operation method for advanced user and basic user).
P.S. - this lookup is not a hash table. The Variant implements the red/black tree and not a hashing algorithm.

Attached Thumbnails

• 

Edited by 0_o, 22 August 2012 - 03:48 AM.

[drjdpowell]

I usually use DVRs whenever I want to use the aggregation pattern (zero or more relationship).

If you’d like to stay by-value and avoid the DVRs, you can instead keep your objects in an array, and store the object’s array index in the variant attribute look up tables.