Performance tweak for LV Classes and "To More Specific" node

[AristosQueue (NI)]

Here's a performance tip about LabVIEW classes and the "To More Specific" node.

This post is for those who really need every drop of performance squeezed from LabVIEW code. It's not going to make much of a difference in most applications, and making the code harder to read is generally not worth a minor speed bump. On the other hand, sometimes, this trick can help you avoid a sizable data copy.

In general, it's better if you can just add a dynamic dispatch VI to your class hierarchy to do type-specific work, but there are some cases where that's just not possible. When that happens, a programmer reaches for the "To More Specific" node to do type testing. Here's a typical piece of code:

This code works! Let me say that again: This code works. It does exactly what you expect: if the object is a particular child type, it modifies the object. If the object is any other type, it leaves the object unchanged. And if the performance of your application is good enough with the above code, I encourage you to leave it alone. It is easy to read, and a pound of readability outweighs an ounce of performance. But if you're hitting some performance road bumps, read on.

So what's the problem? The problem is that this code makes a full copy of the object. When the To More Specific node executes, if the object is not the desired type, then the output is modified to be a default instance of the desired type. That means that the wire branch that has the original value of the object has to be a copy of the object where the original value is preserved. Even though these two wires come back together further downstream, there's no way for the LV compiler to avoid making that copy in the interim (I continue to ask the compiler team to brainstorm in that area in the hopes of some cool breakthrough).

Is there a workaround? Almost. The following workaround does not work in LV 2011, but the compiler has been taught a new trick in LV 2012, and I want to share this with you all now so that any of you writing code today will get improvement when you upgrade.

In LV 2012, the following code will avoid the copy of the object:

 

                                   

We've taught the To More Specific node to be aware when its output is unwired and not tell the compiler that it modifies the input object. That means that the first "To More Specific" just does the type testing and never modifies the object even if the cast fails, so the original object remains available for the case structure. The second "To More Specific" actually does the cast.

This duplication of the To More Specific node does mean you're doing the type check twice, which is a minor performance overhead. For some very small classes, I can imagine that the time to duplicate the object might be smaller than the time to do the second type check, but I seriously doubt that's going to be true for any real type in one of these situations.

So if you're writing this kind of type checking code in 2011 (or earlier) and need a performance boost, you might want to start employing this "double To More Specific" pattern. And then when you upgrade to 2012, your VIs will get the benefit. On the other hand, if your performance is just fine today, leave the code alone and just let the compiler evolve over time until someday it can avoid the copy in the simple code case.

[Darren · Accepted solution]

Thanks for the tip.  Are there any other primitives, off the top of your head, that only perform a subset of their functionality if some of their outputs are unwired?

[AristosQueue (NI)]

Most of them only do subset functionality when an output is unwired. This one also did subset functionality, but it still told the compiler "I may need to modify this input" even though it never actually would modify it. No one noticed this for all these years because it is so unusual to try to stack two To More Specifics to the same class one after another like this, and might have remained unnoticed until I started looking for a workaround to the main issue of copies during type checking.

[Daklu]

So this might be a stupid question, but why are you overloading the To More Specific node with special behavior when the output is unwired?  It seems like you're exposing a behavior TMS uses, but the behavior isn't really what TMS is for.  Wouldn't it make more sense to create a new node that returns the boolean result from a type check?  Personally I think an explicit type check would make the code much easier to read.  And, since the node is right there on the palette, I wouldn't have to worry about trying to remember special behaviors or wade through years of old posts looking for that one nugget of information I vaguely remember reading about.

Just my $.02.