Coerce Dot on a String

[Ben]

Hi DJ,

These concept are so subtle and important to performance that I refuse to let anything into my brain that could confuse me latter if it is wrong (Quoting my Mother "Whatever you do Benny, don't ever get old!").

This is what I can accept (so far)

1) If the source buffer is available for re-use (see top "String 2") the buffer will be re-used and a coercion dot will appear on the sink when it re-uses the buffer.

2) If the source buffer is not available(due to wire-branching for example) for re-use (See bottom (Match pattern output)) a new buffer will be created and no coercion dot will appear.

Remaining Q

A) The wire coming from the "Match pattern" in the bottom example is NOT a typedef'd wire (Float over wire with wiring tool and help window open). The sink of the wire is a typedef. Why no coercion dot?

Ben

[Ben]

Anothe follow-up Q

In the top example were the buffers are re-used but a coecion dot appears....

B) What does "coercion" do if the buffer is being re-used?

C) If I was able to look at that physical memory block, would I see any difference as a result of the "coercion"?

Ben

[DJDDA]

"This is what I can accept (so far)..."

Wait, so I have it backwards? Ugh. Well, keep me posted if you figure it all out to some reasonable degree of certainty.

[DJDDA]

"A) The wire coming from the "Match pattern" in the bottom example is NOT a typedef'd wire (Float over wire with wiring tool and help window open). The sink of the wire is a typedef. Why no coercion dot?"

(Sorry... again, short edit window on posts.)

I think I can answer this, actually: When coercion dots appear, it means that a data value must be changed before the node can read it. If you pass a U32 to an I32 node, you see a red dot and the I32 node never sees a U32.

If you pass a string in need of coercion to the Bundle by Name node, however, apparently it does see the "bad" string in some cases. It'll change it then, but there's no coercion dot for that, because the coercion dot only tells you when "bad" data has been prevented from entering.

[NoahR]

Hi all,

Just wanted to let everyone know that the questions about the coercion dots and the memory for the strings are being looked into further.  I want to make sure that I have a definitive answer for everyone before I respond back.  Thanks for all of your patience!

[DJDDA]

"Thanks for all of your patience!"

You're welcome. Thank you for the update. ^_^

[NoahR]

Hi everyone,

I received some explanation about this topic and I hope this answers everyone's questions.  I hope everyone has a good holiday!

A) The wire coming from the "Match pattern" in the bottom example is NOT a typedef'd wire (Float over wire with wiring tool and help window open). The sink of the wire is a typedef. Why no coercion dot?

There is no coercion dot, but there is actually a “hidden” coercion that is taking place.  In LabVIEW, a sub-string is used in some cases.  This sub-string is a reference to a string.  This is NOT a data type that the user can control and it is not always apparent to the user that coercion from a sub-string to a string is taking place.  The bottom example is converting a sub-string to a typedef to a string.  So in this case, there are two different coercions taking place.  The sub-string to string coercion NEEDS to make a copy.  For some reason, the coercion dots are hidden here.  By looking at the location in memory, the coercion is indeed taking place.  The buffer allocations are present because sub-strings to regular strings need to make a copy since they do not look the same in memory and are unable to share the same location.

B) What does "coercion" do if the buffer is being re-used?

In the top example, no buffers are allocated for the string by the Bundle By Name function.  The inputs to this function are normal strings and the coercion does not require a copy.  The coercion dot is there to show the type differences, but in the case of a string and a typedef string, there is not the necessity to make a copy.

C) If I was able to look at that physical memory block, would I see any difference as a result of the "coercion"?

For most cases that involve a coercion, a memory copy is used for that data, but there are cases where a memory copy is not necessary, like the case for question B.

[NoahR]

Some addition questions that you may find useful and you may have now…

D) Why is there a sub-string produced by the sub-string primitive on the bottom, but not on the top?

The decision to use a sub-string in this case is based on the wiring.  If the primitive uses a sub-string it will propagate a reference to the original string downstream.  It currently will only do this if the input is wired from a single place.  The top picture makes a regular string to output the sub-string and copies that portion of the string into it.  The bottom makes a reference to a portion of the string using a sub-string type, without copying anything.

E) Why do we use sub-strings and sub-arrays?

Our intent is to avoid data copy work if possible.  However the propagation of these references cannot go everywhere (currently we cannot pass the reference types to subVIs for example).  Some nodes have not been equipped to handle sub-strings, so they require coercion.  The sub-types are a tool for the compiler to use to attempt to improve performance.  They are newer (around since version 5 or 6), used in limited situations, and the limits and usage has and will change as we work on the compiler.

F) What is the best way to analyze performance?

The best tool is to look at the copy "dots".  Sometimes a copy dot is caused by a type coercion - then both a coercion dot and a buffer allocation will be shown.  Sometimes we don't show  coercion dots.  I am not certain of the reasons we do this in every case, but the intent is to avoid showing the user type differences over which they have no control.

[Ben]

Thanks you Noah  !

It will take me a little while to read and understand what you have said.

You have used some new terms that I have never heard prior.

I'll post follow-up Q's as required.

Ben

[DJDDA]

Nice! Thank you for the attention to this matter!