Community Nugget 3-12-2007 Implementing sets with variant attributes

[Ben]

Wiebe wrote;

"

We did a little test recently (we don't have benchmarks though). Getting/searching an item is generally faster then searching an array, but inserting new items is slower then simply attaching to an array. If you search an item at the beginning of an array, the array search can be faster, because the search routine will stop as soon as the item is found.


... I'm stuck in 7.1 for now,

"

This is very promising if these results are for LV 7.1.

Boy if I was not dancinge with so many people at the moment I'd chase this in LV 8.2.

At the very worst i'll try to include this twist in the Action Engine Nugget (whenever I get around to writing that one). I am always interested in making action engines go faster.

Ben

[Steve.Briggs]

Hey all,

---

@Tomi M wrote:

p.s. You may want to upgrade to LV 8.20 or later as the speed of variant attributes has increased by a giant leap. Or that's what they say.

---

---

wiebe@CARYA wrote:

Perhaps someone can do some benchmarking? I'm stuck in 7.1 for now, and the variants are not optimized in this version.

---

I feel the pain of being stuck in 7.1...

[shoneill]

Ben wrote: "At the very worst i'll try to include this twist in the Action Engine Nugget (whenever I get around to writing that one). I am always interested in making action engines go faster."

I think I have to wait for a future date to be enlightened as to what Ben's statement means.....

Shane

i.e. What's an "action engine".  Anything to do with G.I. Joe?  😉

[Wiebe@CARYA]

"Ben" <x@no.email> wrote in message news:1173791410781-490717@exchange.ni.com...
Wiebe wrote;
"
We did a little test recently (we don't have benchmarks though). Getting/searching an item is generally faster then searching an array, but inserting new items is slower then simply attaching to an array. If you search an item at the beginning of an array, the array search can be faster, because the search routine will stop as soon as the item is found....&nbsp;I'm stuck in 7.1 for now,
"
This is very promising if these results are for LV 7.1.
Boy if I was not dancinge with so many people at the moment I'd chase this in LV 8.2.
At the very worst i'll try to include this twist in the Action Engine Nugget (whenever I get around to writing that one). I am always interested in making action engines go faster.
&nbsp;
Ben
&nbsp;


Sorry for getting your hopes up. We did the test in 8.2. It's just not my working machine.


I'm also curious about what an Action Engine is...


Regards,


Wiebe.

[Steve.Briggs]

Hey,

An action engine hmmm....is this anything like a runtime engine?

[unclebump]

Nope. They are type2 globals on steroids.

http://forums.ni.com/ni/board/message?board.id=170&message.id=142057&requireLogin=False

[Jarrod_S.]

Great post Tomi!

You do make a great point, however, that you need to be careful on deciding when to use sets. Various situations come to mind when it isn't appropriate, or when users should at least be careful in the implementation.

For instance: You mentioned storing refnums as sets to avoid having duplicate refnums. This was done by flattening the refnum to string for storage. One thing to watch out for is having two refnums for the same control/VI that have separate hex values. If you flatten them to string, the variant set storage won't recognize them as belonging to the same object. At that point it's just string data that's compared bit-wise. (The Equals primitive used to have the same problem. It couldn't properly determine whether two refnums actually referred to the same object. Sometime around 8.0 the Equals primitive was improved to recognize this distinction.)

This next warning is just a gut feeling, honestly. It may or may not have much impact. I'm not familiar with the inner workings of the variant's string comparison algorithm, but I would guess that the algorithm slows down as the string length grows. Maybe it's miniscule, but if the data you're storing as sets starts to reach into the kB or MB range per object, you might see a performance hit when adding new objects, because it takes longer for LabVIEW to determine if this object is indeed new. In many situations, a name-value pair would work better for this type of situation, since the name would always be short.

Just my 2 cents...

[tst]

---

@Steve.Briggs wrote:

An action engine hmmm....is this anything like a runtime engine?

---

More like a fire engine.

Or, since this is Ben, maybe more like a steam engine?

An action engine is Ben's term for a functional global which includes extra actions other than just holding the data.

[Rick B]

Tomi wrote:
"p.s. You may want to upgrade to LV 8.20 or later as the speed of variant attributes has increased by a giant leap."

We were just discussing this at work, and I was under the impression the performance improvements were implemented in 8.0 release according to release notes. Is there any evidence either written or benchmarked showing improvements in 8.2?

Interesting post on Sets. I think however it is more than a nugget-more like an LTR article. Hey, LTR lives on in the forums!

Posted this on Breakpoint by accident-sorry working in a cramped env at the moment.

Thanks, Rick

[Tomi_Maila]

Yes, the feature was upgraded in LV 8.0, however if I cannot recommend upgrading from LV 7.1.1 to LV 8.0 as LV 8.20 is more stable. I strongly recommend you reading this thread from start to end.

Well, I'm considering founding my own blog where I will deal with programming techniques, perhaps I can write more articles like this over there. If there are other pros who volonteers to keep blog on programming techniques, I welcome them to keep their own blog on my site. I wonder if it will be ok for NI if I post a notification of my forthcoming articles to somewhere on this forum.

Tomi

Message Edited by Tomi M on 03-14-2007 06:32 PM