When to use in place structure and data reference

[wetland]

Hi

This is my first code question on this site.

I am at the moment playing with data references and in place structures.

I would like to know when it is best to use this code.

In the test vi l have provided l am removing -1 from arrays. This could be zeros if required. The test code is to be used in an image analysis program l am starting to think about.

I like both code performance and best use of memory in my code development. The vi l have provided is to see what you think as well for me to get to use this site. For me the test vi does not provide me as to a clear path as to how l should code. That is not using in place structures with data reference or just use standard numerical array code.

VI (When to use In Place Element Structure) is a LV 2012 version

[Mark_Yedinak]

You do realize that you do not need to use the DVR in this code. You can wire the arrays directly to the in place element structure. You would use the DVR if you were passing the data via a reference to other parts of your code such as subVIs.

[altenbach]

I am totally confused on what you are trying to show. Especially your diagram comment: "Use highlight execution to determine which code provides the fastest results" makes absolutely no sense. The speed under highlight execution is directly proportional to the number of nodes and the lenght of the wires and has absolutely nothing to do with performance.

If you want to benchmark your various code versions, it will be significantly more complicated. What are you trying to prove? What is the point of DVRs at all here?

Your data value references require new buffer allocations anyway, since your array size is changing. As a first step, show the buffer allocations and count the dots.

[crossrulz]

As has already been said, this is NOT an appropriate use of the DVR.  The point of the DVR is to share data amonst multiple threads.  You are not doing that here.  Just use the Replace Array Subset.

[wetland]

Hi all

Thank you for your responses, especially from 3 such experienced programmers.

At the moment without the DVR in the inplace structure l have not been able to get the same result as with all the other code l have provided.  When you use the vi l have provided you will find that only the 5 to 12 are provided in a new array that is short as possible. These are simulated answers as to which row had a pixel in an image. So if l have extra zeros these would indicate that row zero had a pixel which in this example it did not.

When you apply the execute command the fastest code is just the basic numerical array code, followed by whole array being placed in the in place structure using the DVR. I do not know if that was a go idea. I would like a comment on your experience with that feature.

I am interested in the comment by altenbach that DVR requires new buffer allocations since array size is changing. I do not understand show buffer allocations and "count the dots".

At the start of this exercise l liked the numerical array code but l found it interesting that with the final answer for DVR the indicator provided no memory allocations when testing code via the vi analyzer. From your comments l believe l should code as seperate vi's for each type of code to test memory allocations.

At the moment l have not been brave enough to use LVOOP code in large programs. And l have not yet used DVR or in place structure. My last LV program was 8.6.1. where these features were no used as often as l see in LV 2011 and LV 2012. I finally have LV 2012 working at home so during the Christmas break l have been updating myself. I like the feature that DVR can be detected by other vi's but in this example that is not required. In a large program can you run into problems with a number of DVR's? E.g. identification. If so would using LVOOP for each DVR be a way out of this problem or do just have to label each DVR with a different name? If you have a number of DVR's in a large program can this slow a program down? Is it better to use direct wire connections instead? At the moment l tend to avoid using variables and prefer to use direct wire connections. The problem is l end up with a program with many layers of sub vi's. Is this bad code practice?

[altenbach]

---

wetland wrote:

At the moment without the DVR in the inplace structure l have not been able to get the same result as with all the other code l have provided.  When you use the vi l have provided you will find that only the 5 to 12 are provided in a new array that is short as possible. These are simulated answers as to which row had a pixel in an image. So if l have extra zeros these would indicate that row zero had a pixel which in this example it did not.

---

All the code you have provided gives the same result. I don't understand what you are saying. Can you attach some code that gives a different result?

---

wetland wrote:

When you apply the execute command the fastest code is just the basic numerical array code, followed by whole array being placed in the in place structure using the DVR. I do not know if that was a go idea. I would like a comment on your experience with that feature.

---

Define "fastest". None of the code fragments have any pH, so I don't know which ine is "basic".

---

@wetland wrote:

I am interested in the comment by altenbach that DVR requires new buffer allocations since array size is changing. I do not understand show buffer allocations and "count the dots".

---

Go to menu...tools..profile...show buffer allocations. Count the dots.

---

@wetland wrote:

At the start of this exercise l liked the numerical array code but l found it interesting that with the final answer for DVR the indicator provided no memory allocations when testing code via the vi analyzer. From your comments l believe l should code as seperate vi's for each type of code to test memory allocations.

---

Which VI analyzer test are you using?

---

@wetland wrote:

 I like the feature that DVR can be detected by other vi's but in this example that is not required. In a large program can you run into problems with a number of DVR's? E.g. identification. If so would using LVOOP for each DVR be a way out of this problem or do just have to label each DVR with a different name? If you have a number of DVR's in a large program can this slow a program down? Is it better to use direct wire connections instead? At the moment l tend to avoid using variables and prefer to use direct wire connections.

---

I don't quite understand everything you are saying.

When you create a data value reference, make sure the control or constant wired to it has a label. This label will propagate along the reference and can be seen in the context help.

Why would a DVR slow down your program? Why would it slow down as a function of program size? If anything, it will speed it up by limiting the number of duplicate data copies. The IPE protects from concurrent access.

[wetland]

Hi Altenbach

You have cleared some of my grey areas but l somehow have provided you with some grey areas.

"All the code you have provided gives the same result. I don't understand what you are saying. Can you attach some code that gives a different result?"

You can change the numbers. I think that may be the zeros is for you a problem. Ok What l have is an answer of 5 to 12. I do not want an answer of 5 to 12,0,0,0. For me the zeros would represent a pixel on row zero. I cannot have code that artificially provides a zero after an image has been analyzed. I am happy that all the code l have provided the answer l want. What l am trying to obtain is some of your experience of inplace structure and DVR as when to best use it. Your following answers to other parts of your reply have helped.

"Define fastest."

Ok when using execution the first code that provides an answer is the numerical array code. This is important for to know because images contain a large volume of data. But l am also interested what is best code for large programs because simple vi code perform better than a large program. For me it is clear that for a simple vi the numerical array code is the best. However l would like to know if the use of DVR and Inplace structure code would be far better to use for large programs. E.g.. provide better performance etc.

"Go to menu...tools..profile...show buffer allocations. Count the dots."

Thank you for this. I have forgotten about this tool.

"Which VI analyzer test are you using?"

The standard VI analyzer that comes with LV. (Tools -  VI analyzer - Analyzer VIs) This is one of the best programs in LV. It is like having a mentor beside you as you code. I use it all the time. The analyzer normally comes up with waste of memory for data left in indicator arrays or graphs. Then you have to provide code to clear the array or graph.

"When you create a data value reference, make sure the control or constant wired to it has a label. This label will propagate along the reference and can be seen in the context help.

Why would a DVR slow down your program? Why would it slow down as a function of program size? If anything, it will speed it up by limiting the number of duplicate data copies. The IPE protects from concurrent access."

What a good answer. This has cleared some of my grey areas.

My new questions are:

What do you mean by IPE protects from concurrent access?

Do you normally count the buffer allocations when you program? E.g.. count dots. Less dots better code.

Do you use DVR and in place structure in your code often?

I noticed that in LVOOP you can open up a vi and all you see in the VI is input and output wires connected to an in place structure. So it seems to me that this is code l should place every where l can in a large program. Is this correct?

[RavensFan]

---

@wetland wrote:

"Define fastest."

Ok when using execution the first code that provides an answer is the numerical array code. This is important for to know because images contain a large volume of data. But l am also interested what is best code for large programs because simple vi code perform better than a large program. For me it is clear that for a simple vi the numerical array code is the best. However l would like to know if the use of DVR and Inplace structure code would be far better to use for large programs. E.g.. provide better performance etc.

---

I still don't understand how you are using highlight execution to determine what is the fastest or what is first.  Highlight execution is designed to help you debug code and see what data is on the wires and what cases are executing.  If you want to benchmark code, it is definitely something you don't use.  You would use each of your "examples" in different VI's with a timestamp before and a timestamp after the execution of your code.

[wetland]

Hi RavenFan

You wrote:

"I still don't understand how you are using highlight execution to determine what is the fastest or what is first.  Highlight execution is designed to help you debug code and see what data is on the wires and what cases are executing.  If you want to benchmark code, it is definitely something you don't use.  You would use each of your "examples" in different VI's with a timestamp before and a timestamp after the execution of your code".

Hi Raven you are correct in execution timing. I never have time for the benchmark code so l have used profile performance and memory. I rarely have to use execute highlight but when l do is to find out which part of the code is executing first and as you say for troubleshooting. The most common time l use it is to see what part of the code is executing first in areas where l have one data source l have a number of data analyzing sections of code using that one data source.

I have now got off my butt and developed separate code for each type of array and performed the profile performance and memory tests. In doing so l have answer one of my questions to Altenbach. I have found that it is best to place the whole array in the inplace structure element vi instead of part of it.

When reviewing my profile file you will see that the numerical array without -1.vi and numerical array without -1 with DVR and inplace element structure.vi equally provide an execution speed of 15.6 mSec. And in terms of max byte size the smallest memory usage is by numerically array without -1.vi (3.24k) closely followed by numerical array without -1 with DVR and in place element structure.vi (4.39k).

I let you view the profile file. You guys may be able to provide more comments.

For me it's still a grey area as when to use both DVR or in place element structure for large programs. If from experience you have examples where this type of code is best used l will be grateful. I now see it as another way to remove default data left in array indicators or graphs when VI analyzer detects a waste of memory. But l would be grateful for more examples. At work l have no time to play with code variations.

I have tried to attach a number of vi's but was prevented by a limit of files.

[RavensFan]

---

@wetland wrote:

Hi Raven you are correct in execution timing. I never have time for the benchmark code so l have used profile performance and memory. I rarely have to use execute highlight but when l do is to find out which part of the code is executing first and as you say for troubleshooting. The most common time l use it is to see what part of the code is executing first in areas where l have one data source l have a number of data analyzing sections of code using that one data source.

---

Actually, highlight execution does not tell you what code will execute first under regular execution.  Under regular execution, and on a PC with multiple cores, two pieces of code can execute simultaneously.  But it won't look that way under highlight execution because LabVIEW needs to slow down the code and show only one wire executing at a time so that you can see it.  Which piece of code it executes first can be arbitrary.

To prove this, go looking through the forums for the hundreds of posts where someone claims there code doesn't work right giving the wrong or unexpected result, while it seems to work okay in highlight execution.  These people are the ones who don't understand data flow and are using local variables incorrectly causing a race condition.  Yet when they run in highlight execution, the results of the race can be different because LabVIEW has determined to schedule and execute the code differently.

If you have a concern about what code executes first or second or last, highlight execution will not help you.  You might fine that something could execute first on one PC, but something else might execute first on another PC if LabVIEW decides to compile the code differently because of processor architecture.  If code execution order ever matters to you for something otherwise you have problems, then you need to make sure you write your code in LabVIEW to account for that.