Darren's Weekly Nugget 10/09/2006

[Darren]

The following tip has been on my list of possible nuggets for a while, but since it has recently been discussed on LAVA, I figured I should go ahead and mention it before it becomes old news.  🙂  It's basically a faster way to accomplish the following:

You see here that we have a data structure where objects are identified by their names.  We could probably make this code easier to read (and possibly faster) by maintaining a separate array of the names and simply searching that array with Search 1D Array:

Both of these methods are inherently linear searches.  It turns out that the following method of accessing the data is much faster:

I had never given much thought to Variant Attributes until this trick was shown to me.  You can basically store each data object as a different attribute of some dummy variant.  I say it's a "dummy" variant because its actual value and datatype are inconsequential...we're purely using the variant to gain access to its attributes as a data store.  I'm no computer scientist, but apparently the variant attributes are stored using a "red/black tree" algorithm, which ends up being an order log(n) search...this is much faster than an order n search, which is what the While Loop or Search 1D Array approach would be.

So the next time you find yourself creating a string array lookup similar to one of the two traditional approaches above, try giving the Variant Attribute approach a try.  Note that this approach is recommended for LabVIEW 8.0 and later, due to some performance improvements with variants that did not exist in LabVIEW 7.1 and previous.

-D

P.S. - Check out past nuggets here.

Message Edited by Darren on 10-09-2006 11:14 AM

[JeffBoettcher]

Interesting, but unless I missed something (entirely possible, mind you) a few details remain to be explained.  Does this assume that the Object Data cluster contains a string?  If so, does said string have to be at the "top-level" of the cluster?  If there are multiple strings in Object Data, does it use the first one in the cluster order, the highest-level one, etc?

I also don't quite understand, the first two find an item with a particular name in an array of clusters.  The variant approach looks like it is doesn't have any arrays in it, so what is it searching through?

Message Edited by Jeff B on 10-09-2006 11:27 AM

[Darren]

Object Data can contain whatever you want...it's just that whenever you add the object data to the variant attributes, you're associating a specific name (the attribute name) with that data for looking up later.  You can check out the LAVA discussion I linked above for more details if it's still unclear.

-D

[Ben]

Is there anyone out there who would like to translate this nugget for the "variant diabled" (like me!) ?

Given the "Old way" what would I have to do to convert my code to the new way?

Ben

[Jarrod_S.]

I'm attaching a simple example that should help a little. The best way I can phrase this is to think of the dummy variant Darren described more as a refnum to some storage. The refnum itself is meaningless, but it allows us to call functions (like Get/Set) on that specific storage in memory.

So we can store any type of data object as a name/value pair inside the variant and then retrieve those values by name. You pass around the variant data like you would a refnum. The big difference in this analogy is that if you copy the variant, you copy the entire storage, which is not what happens with a refnum or any other type of reference.

Message Edited by Jarrod S. on 10-09-2006 01:10 PM

[Ben]

Thank you Jarrod,

I will attempt to review your example within the next couple of days ( I'm still working a LV 7.1 project at work, my LV 8.20 machine is at home).

I am always looking for faster ways to serach through lists of stuff, so I am hoping for an epiphany (sp?).

Ben

[Jarrod_S.]

This is the jist of the code I attached, with constants instead of controls so you can see what's going on. Hope this helps!

Message Edited by Jarrod S. on 10-09-2006 01:23 PM

[JeffBoettcher]

Yes Jarrod, your example clears things up nicely.

To elaborate slightly, part of the story is in changing the way you're storing your data in the first place (the part through and including the for loop in your example).  The first two examples above show an array of clusters, each element containing the name of that item.

Variant attributes are effectively name/value pairs, where value can be any datatype.  What you're doing here is removing the (redundant) name from the data cluster and using it as the attribute name, then using each array element as the attribute value.

Once you've stored data in this way, that's when you can use the trick Darren mentioned for speedy lookup.

Message Edited by Jeff B on 10-09-2006 01:29 PM

[Darren]

Sorry I wasn't more clear in my original post.  Here is an example VI I wrote demonstrating the power of the Variant Attribute lookup table.  One of the most common use cases I have for a lookup table is when I have data associated with different items in a Tree Control.  Since the items are stored in the Tree Control as string values (tags), I often have a data structure (in the form of a cluster) associated with each item in the tree...I identify the tree items using their tags, and thus must look up the data for a particular tag by its name...my old approach was to either keep the tag as part of the data structure (the While Loop example above), or maintain a separate string array and use Search 1D Array to find the items in that array.  Instead of taking these approaches, we have the alternative of using Variant Attributes to make name-value pairs that are more quickly accessed than the standard linear search through a string array.  In the example VI, we are simply reading the selected tag in the tree control and accessing the data for that specific tag through the Get Variant Attribute function.  Hopefully this example VI clears up some of the confusion.

-D

[Ben]

Thank you all very much!

Star to all.

Ben