Re : Manipulating DVR Data - Is this correct?

[nathand]

I have no idea about the details of the LabVIEW compiler, but according to everything I've read, yes, there's no performance difference between those two pieces of code.

[Mr._Jim]

---

@nathand wrote:
I have no idea about the details of the LabVIEW compiler, but according to everything I've read, yes, there's no performance difference between those two pieces of code.

---

That's what I gather as well. I'm curious to know definitively, though, whether in this case the compiler makes a copy of the cluster without the IPE. My guess is that it doesn't, based on what I'm reading in the compiler white paper?

[nathand]

I'm not sure this is a particularly good example. Potentially the entire thing can get constant-folded. Even if it can't, nothing happens in-place here because block diagram constants always get copied when modified (the value of the constant has to stay constant - that value is stored in the VI itself, and a VI can't modify its own code).

Replacing the constant with a control wouldn't change my answer, though.

[nathand]

---

@Gregory wrote:

I just wanted to get some experience with a new concept so I started building it into a project I've been working on. I've also seen a couple sources like this one, which suggest that DVRs should be used instead of FGV when possible.

---

Ah, I see. In that case, yes, replacing a functional global with a DVR is reasonable. It won't be "more efficient" but it will be more flexible and extensible.

I would contrast that presentation with this comment from NI R&D about reference types (although in this case they're referring more specifically to LabVIEW classes): "Be aware: Reference types should be used extremely rarely in your VIs. Based on lots of looking at customer VIs, we in R&D estimate that of all the LabVIEW classes you ever create, less than 5% should require reference mechanisms. If you find yourself doing more than that, think about ways to use more by-value classes, because you are almost certainly needlessly costing your self performance."

I haven't seen any comments about the extent to which this applies to reference types generally, outside of classes.

[JÞB]

---

@Gregory wrote:

Thank you for all the info Nathan. I have one question pertaining to the IPE when dealing with clusters. Is the only difference in this code cosmetic?

---

No, the difference is just a bit more than cosmetic.  <Duct- tape your head>  Depending on the version of LabVIEW used there are differences in the behavior.  In either case the IPE adds a "Synchonization Boundary" on the IPE input and output.  This is mere mircoprocessor oprerations and is very small! when LabVIEW 2009 introduced the IPE the top code knew to re-use the buffer containing the cluster.  Since then (2012 and later) the new compiler recognizes that the lower code could re-use the buffer that the Cluster resides in and this "Magic Pattern" is optomized to do exactly that- Reuse the buffer.  Without the added overhead of the IPE's Synchronization boundies.  Further complier optimizations may make the point moot and both code elements may be equal in performance.  

When dealling with large data that needs a lot of access Benchmark your code carefully if you must have optimal performance

[JÞB]

---

@Gregory wrote:

Thank you for all the info Nathan. I have one question pertaining to the IPE when dealing with clusters. Is the only difference in this code cosmetic?

---

No, the difference is just a bit more than cosmetic.  <Duct- tape your head>  Depending on the version of LabVIEW used there are differences in the behavior.  In either case the IPE adds a "Synchonization Boundary" on the IPE input and output.  This is mere mircoprocessor oprerations and is very small! when LabVIEW 2009 introduced the IPE the top code knew to re-use the buffer containing the cluster.  Since then (2012 and later) the new compiler recognizes that the lower code could re-use the buffer that the Cluster resides in and this "Magic Pattern" is optomized to do exactly that- Reuse the buffer.  Without the added overhead of the IPE's Synchronization boundies.  Further complier optimizations may make the point moot and both code elements may be equal in performance.  

When dealling with large data that needs a lot of access Benchmark your code carefully if you must have optimal performance.

[nathand]

---

@JÞB wrote:

when LabVIEW 2009 introduced the IPE the top code knew to re-use the buffer containing the cluster.  Since then (2012 and later) the new compiler recognizes that the lower code could re-use the buffer that the Cluster resides in and this "Magic Pattern" is optomized to do exactly that- Reuse the buffer.  Without the added overhead of the IPE's Synchronization boundaries.

---

I might be mistaken, but I thought the unbundle/bundle "magic pattern" had been around a lot longer than that?

Note that the "magic pattern" only works if the modify operations are fairly simple. If you unbundle an array, then index out one element, modify that, put it back into the array, and re-bundle, the compiler can no longer identify that as something that should happen in-place. Or at least so I was told a few versions of LabVIEW back.

[JÞB]

---

@nathand wrote:

---

@JÞB wrote:

when LabVIEW 2009 introduced the IPE the top code knew to re-use the buffer containing the cluster.  Since then (2012 and later) the new compiler recognizes that the lower code could re-use the buffer that the Cluster resides in and this "Magic Pattern" is optomized to do exactly that- Reuse the buffer.  Without the added overhead of the IPE's Synchronization boundaries.

---

I might be mistaken, but I thought the unbundle/bundle "magic pattern" had been around a lot longer than that?

Note that the "magic pattern" only works if the modify operations are fairly simple. If you unbundle an array, then index out one element, modify that, put it back into the array, and re-bundle, the compiler can no longer identify that as something that should happen in-place. Or at least so I was told a few versions of LabVIEW back.

---

Array opreations will happen in-place if possible. (Post 2009?)  Bundle/ unbundle may happen in-place.  Benchmarking your use case is best in all situations while the NI R&D team gets "Creative" and the compiler gets smarter!  

2010 "May" have indtroduced some of those "Magic Pattern" optomizations for "Brown" clusters.  I first saw one in 2011- with a benchmark vi!  

 NOTE: This example uses a "Pink" Cluster... Yup, that String may have variable length so.... all bets are off!  I do not know when or how the IPE did optomize it. but I could offer a few theories on how to do that.

Usually, we LabVIEW users do not need to worry about some of the really subtle stuff that NI R&D does for us, sometimes it can get frustrating trying to outguess the brilliance of those geeks.   

[Ben]

For those that are curious "how to interpret the entrails" of LV and get a handle for yourself on when how buffers get re-used you may want to review this old thread where we worked through the answer using bench marking tests and show-buffer allocations.

Jeff is correct that the people in The Ivory Tower have done a great job but ath the same time, we have to be able to figure out when they missed something. If you do find a situation that makes seanse, plese share an example so we can get it fixed.

Ben

[Ramprakash0111]

can u please say how DVR exactly works ?

and for what ?