Flatten Unflatten vs TypeCast - Speed Test

[CoastalMaineBird]

LV2013

As is my custom, I checked out two alternate ways of doing something, to see which was faster.

Objective: To convert a "Generic" U8 Enum to a "Specific" U8 Enum.

IOW, both are TYPEDEFed enums with 256 values.

One will remain generic, to be used in a generic transceiver method, the other will be specific, to be used in a specific application.

Directly connecting a generic control to a specific indicator will not work, as LV (properly) complains that they are not compatible.

Scheme 1 flattened the Enum into a string, then unflattened it as the specific type:

Scheme 2 does a typecast from general to specific:

Both are in INLINE SUBROUTINE VIs, so call overhead should be ruled out.

My Timing mechanism is well tested, been used for 20 years.

I was surprised to find that the FLATTEN + UNFLATTEN scheme was faster.  Significantly.  (227 nSec vs. 393 nSec).

My question (strictly academically) is WHY?

My thought is that the TYPECAST simply reuses the space occupied by the incoming variable and re-declares it to be the new type. IOW, no time at all.

Whereas, the FLATTEN has to allocated space for a string, create a LENGTH word, then take the string and extract one byte and create a new variable.

Obviously I am mistaken, so WHY?  Is the optimizer really smart enough to figure out what I'm doing and bypass some of that?  If so, why not on the TYPECAST case?

The VIs are attached if you care to play with it.

[mcduff]

It is my understanding that typecast ALWAYS makes a copy of the incoming buffer, it is not reused.

Make a large numeric array of doubles and save them to a binary file, for one case connect the the array directly to the write binary file VI, for the other, insert a typecast in between, watch your memory double.

Cheers,

mcduff

[nathand]

What if you use "To Unsigned Byte Integer" instead of Type Cast or the unflatten? That should be essentially a no-op, and I bet it's faster.

[crossrulz]

I am curious if the Coerce To Type might make a difference.

[dan_u]

Did you try Coerce to Type? This is supposed to do what you would expect from Typecast: reinterpreting the data without copying it when possible.

I use Coerce to type often, e.g. to convert a scalar to an enum (also on RT systems), and it is way faster.

Edit: crossrulz beat me to it 

[CoastalMaineBird]

It is my understanding that typecast ALWAYS makes a copy of the incoming buffer, it is not reused.

But given that the "buffer" in this case is a single byte, I would not expect it to take longer than flattening (making a new buffer) and unflattening (making another new buffer).

[CoastalMaineBird]

What if you use "To Unsigned Byte Integer" instead of Type Cast or the unflatten?

Indeed that makes a big difference:

While that's a GREAT answer for "How do I do this faster?", it's NOT an answer for "Why does Flatten+Unflatten go faster than TypeCast?" which was my original question.

[CoastalMaineBird]

I am curious if the Coerce To Type might make a difference.

Yes, but not in a good way.  It's broken, with the complaint of "Enumeration Conflict".

[Yamaeda]

How does Variant to data compare?

/Y

[altenbach]

Both seem slower than expected to me, but I don't think the difference is really significant (less than a factor of two). Are these average times or shortest times? What's the variability?

---

@CoastalMaineBird wrote:

Both are in INLINE SUBROUTINE VIs, so call overhead should be ruled out.

---

Once they are inlined, the priority is irrelevant (... if you are talking about "subroutine priority". Or are you using it in the generic term for a subVI?)

---

@CoastalMaineBird wrote:

Obviously I am mistaken, so WHY?  Is the optimizer really smart enough to figure out what I'm doing and bypass some of that?  If so, why not on the TYPECAST case?

Yes, we have no idea what the compiler does with all that. It might have very little resemblance to the graphical code. I often see factors of two between seemingly and functionally identical code with subtle differences. Hard to tell....