Object Orientated By Ref Pass Object Through

[Richard_Ha]

I've got an array of objects which have a DVR as their data. If I update this data, becuase it's updating the DVR by ref I don't need to pass the "updated object" back out of the for loops. This would save processors time (not building an array to pass out). Am I correct in this assumption? It would make my code a lot neater by not having to rebuild the array of objects to pass though.

Ordinarily I'd be doing it like the top example, but becuase it's by DVR I'm assuming I can use the bottom example?

[mikeporter]

Yes, update the DVR anywhere and the modified data is available everywhere. But remember:

"With great power comes great responsibility"

Race Conditions... 'nuff said...

Mike...

[Intaris]

The top example doesnt build a new array. The compiler is clever enough to reuse the array already in memory.

Even with by ref i would choose the upper code.

[drjdpowell]

---

@Richard_Ha wrote:

This would save processors time (not building an array to pass out). Am I correct in this assumption? 

---

No.  Your upper code in English is "Write false on each element of the array, then call Halt on each element".   Your lower one is "Make a copy of the array and Write false on each element, then make a another copy of the original array and call Halt on each element".  Because your making copies of DVR references, the two codes will act the same.   But the upper code is the neater one.  And the one that might possibly have a slight performance advantage (though I suspect the compiler may avoid actually copying the references).

[Yamaeda]

I'd merge them to one loop and parallellize it, based on the upper one.
/Y

[Richard_Ha]

Thank you for the responces. My example is slightly more complicated than this which is why I asked the question.

My real example has a Cluster which contains and Array of Axes Objects and a Move object.

I have a VI which seraches the Array of Axes and returns the array and the found axis, having to keep track of it's index and replace is back in to the array is a bit of a mess which is why I wanted to check that I could get away without having to "replace" it back in to the array. Below is still faily simple example. There are places where I have to perform multiple actions on the axis and would rather not repalce it back in the array an then build the cluster again.

[smithd]

---

@Richard_Ha wrote:

My real example has a Cluster which contains and Array of Axes Objects and a Move object.

I have a VI which seraches the Array of Axes and returns the array and the found axis, having to keep track of it's index and replace is back in to the array is a bit of a mess which is why I wanted to check that I could get away without having to "replace" it back in to the array. Below is still faily simple example. There are places where I have to perform multiple actions on the axis and would rather not repalce it back in the array an then build the cluster again.

---

It looks like you'll probably make a copy of the individual axis here, but won't make a copy of the main cluster wire. You can get into trouble sometimes with data inside of clusters, since LabVIEW treats it all as one block, and with DD, since I've noticed LV sometimes treats dynamic dispatch methods as writers on the dataset.

If that sounds really confusing, thats the intent. The LabVIEW compiler is very advanced. If you have your VI written and you are seeing performance issues, thats when you should try to figure out what is going on and maybe that involves asking questions like these. But for now, you probably shouldn't worry about it too much.

If you do ever get to the point where you are seeing issues and want to optimize, you should start with the buffer allocations tool: http://zone.ni.com/reference/en-XX/help/371361K-01/lvdialog/show_buffer_alloc/

For some reason, people claim that it lies a lot. I've never seen that be the case. There might be situations where it over-estimates, but if you have a performance hotspot, and the tool shows a buffer allocation on a giant cluster, thats probably the cause of your hotspot.

For your particular situation, I'd recommend turning on buffer allocations for arrays and clusters and see if anything you are doing is generating an extra copy.

[nathand]

---

@smithd wrote:

For some reason, people claim that it lies a lot. I've never seen that be the case. There might be situations where it over-estimates, but if you have a performance hotspot, and the tool shows a buffer allocation on a giant cluster, thats probably the cause of your hotspot.

---

I suspect it's because people don't always understand what a buffer allocation means. Inside a while loop, a buffer allocation could mean that memory is allocated only once and reused, or it could mean that new space is required on each iteration. Also, memory allocation is relatively fast, whereas copying data is slow, and there's no way to see exactly where copies are being made. You could have a situation where your code makes duplicates of a large array, and you wouldn't see a buffer allocation if the arrays were already allocated, but there would still be a performance hit. Conversely there are situations where there appears to be a large allocation, but it's actually quite small and very little data is copied, as explained in Another reason why "copy dots" is a bad name for buffer allocations.

[PiDi]

This might be a long shot, but I often find implementing such arrays of objects as collections (or more generally - as aggregate) very profitable. Take a look at this:

Your problem is that you don't want to keep track on where to actually insert/replace the Axis in the array of Axes - probably because you'd need to do it in many places. By creating AxesCollection you'd have single place where you'd need to identify Axis index in the array (that is UpdateAxis). You could optimize the updating operation by keeping the "AxesIdentifiers" (or "AxesNames", or whatever) array together with Axes array to quickly find the specified Axis in the collection.

This is not very complicated design, but it is certainly one of the cases wher OO can really simplify your project by hiding the implementation details 😉

[Richard_Ha]

Thanks PiDi.

I'll look more in to that when the code end up having it's next restucturing, which I'm sure won't be too long after this one!