LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Coercion dots?

Hi,
I have been told that it's better to not have coercion dots throughout my block diagram so I wen through and everywhere I saw one I made sure to use a number conversion before it, but now I think my VI might run even slower. I just wanted to know if it saves any execution time / memory to replace the coercion dots with an actual number conversion function? Basically what should be done to avoid them if it's not always possible to change the original input's representation,
thanks
0 Kudos
Message 1 of 3
(3,070 Views)
> I have been told that it's better to not have coercion dots throughout
> my block diagram so I wen through and everywhere I saw one I made sure
> to use a number conversion before it, but now I think my VI might run
> even slower. I just wanted to know if it saves any execution time /
> memory to replace the coercion dots with an actual number conversion
> function? Basically what should be done to avoid them if it's not
> always possible to change the original input's representation,


Unfortunately, this simplified advice leads to extra editing work
without necessarily gaining any benefits. The coercion dots are often
the same as placing an explicit conversion bullet on the same wire. In
certain cases, such as when an integer and a float are both wired to
plus, LV will generate code that picks up an integer and a float and
performs the operation. It will draw a coercion dot on the integer
input, but the the converted float is never stored in memory. If an
explicit conversion is performed, LV will convert the integer into a
float and the plus will load two floats. The difference is quite small,
but the implicit coercion is more efficient.

I believe the performance chapter gives an example where an explicit
conversion is more appropriate. The example has an integer being
generated and collected by a loop into an array. Later the array is
converted from integer to float, meaning that both of the arrays exist
at the same time. If the elements of the array are converted to floats
before being built into the array, then the integer array never exists,
only the float and this is more efficient in both storage and execution.

In otherwords, the rule isn't as simple as always or never placing
conversion nodes. In general, don't bother with coercions on wires that
aren't a large array or typedef. In those cases, look upstream to see
if it is possible to change the way the data is generated to make it
match. In particular, watch for how the data is built. Converting the
smaller items to the correct type before they are built into the larger
one can save memory and time.

Finally, you should always consider using the profiler to see if the
diagram has performance problems to begin with.

Greg McKaskle
Message 2 of 3
(3,070 Views)
Greg,

I have heard some information from other NI members that there may be a way to find the coersion dots, or more importantly, where LabVIEW is making copies of data. It was mentioned to work in LabVIEW 6.1 I believe but I could not find any information about it or try to get it to work. It would be very useful to have a tool that could perform this step. I was told that it would perhaps draw lines in red or something? I am using a nested case structure 4 levels deep with 1 or 2 shift registers in each. Any help would be greatly appreciated!
Thanks - Kevin
Kevin Shirey | CLA | Champion | Senior Project Engineer II | DMC
0 Kudos
Message 3 of 3
(3,070 Views)