Understanding DVRs - II

[CoastalMaineBird]

---

Intaris wrote: 

I would question the assumption that the IPE auto-generates a refnum as this buffer allocation also appears with a single IPE does it not (without sharing DVR between structures)?

---

Yes, it does.  The multiple IPEs are there in my examples as ALTERNATE ways of doing it, not that they were intended to work in parallel. The single one at the top was my first go, and it shows the buffer Allocation.  The second one was just a guess to see if it made a difference - it doesn't.  Same for the third.

Yes, the IPE should serve as a Mutex, guaranteeing that only one piece of code can access the resource at one time.  But that doesn't require a buffer copy.

It DOES make sense to interpret it as a POSSIBLE buffer allocation.  If the DVR were invalid, the IPE has to choose:

1... Execute NONE of the code inside it, because there is no data to work with.

2... Create some default data, so that the code inside can operate on SOMETHING.

If they chose #2, then they would have to create a buffer at the de-reference point.

That sounds reasonable.

[CoastalMaineBird]

This little test offers some insight to that idea.

I create a DVR to some data.

I force the reference to be invalid, by casting to U32 and adding 1.

Yet when I dereference it, I still get data.  It's default stuff, but there is still space for a string and space for an integer. 

It didn't come out of nowhere, so it had to be allocated.

(The allocation occurs regardless of whether the indicator is attached or not).

My policy has always been to trust LV to handle things.

Most of the time, that works out OK.

I have to believe that, since the WHOLE POINT of an IN-PLACE thing is to do things IN PLACE, then it will do that IF IT CAN, but that it will do the correct thing REGARDLESS.

If I believe that, then the allocation dot is simply an indication that it MIGHT allocate something here, not that it WILL.

it's the compiler that shows the dot, I suppose.  But the runtime might have code like:

if DVR is valid

    Set pointer to DVR's data

else

    Allocate some data to match the type of DVR.

So there's an allocation.

[Ben]

I do not have time now to verify the following speculations and thoughts.

I do not read the dot @ #2 as saying "allocate memory when this code executes". I read it as "there is memory allocated that is accessed here".

Experiment using a huge data set of 100Meg or more. Do your DVRs in parallel and see if memory usage scales with the number of in-place element structures. I suspect not. The in-place structure will access the same buffers but the in a mutually exclusive manner.

Profile buffers may shed some light on what is happening.

As I said just my first reactions to the question.

Ben

[Ben]

Additionally...

A constant in a FP control has a buffer associated with it. It does not mean the buffer is allocated when the control is read, rather it shows that a buffer exists for that data.

Ben

[Norbert_B]

---

@CoastalMaineBird wrote:
[...]

Yet when I dereference it, I still get data.  It's default stuff, but there is still space for a string and space for an integer. 

[....]

---

Nope, you get no data at all. Indicators have their own buffers to store data for "asynchronuous" display in order to fasten up VI execution speed when passing data to the display. These buffers do initialize to the default value of the data type (or custom value if set as default).

[Intaris]

You just need to compare the situation between IPE operations which MAY fail versus ones which per definition cannot fail.  IIRC, the only one which per definition cannot fail is the unbundle and bundle operation.  Here, there is no buffer allocation shown.

All others must show the buffer allocation because they might, possibly, could need to allocate memory.

Now we can tell, by looking at the code, that certain operations will NEVER need to allocate that buffer (DVR and Variant options), but the compiler doesn't.  The array operations may or may not depending on  he length of the input array.

PS I have had the case where using a lot of inlined VIs led to my compiled code complexity growing to a point where the LV compiler could no loger do the automatic in-placeness of a simply unbundle-operation-bundle (without IPE).  By manually replacing the unbundle bundle with IPEs, my performance hugely increased (it was on RT so memory allocations were prohibitive).  It's a corner case but I have seen huge differences and I have again grown fond of the IPE for simple unbundle bundle operations.  Sometimes I just know better than the compiler can possibly evaluate on-the-fly.

[CoastalMaineBird]

Nope, you get no data at all. Indicators have their own buffers to store data for "asynchronuous" display in order to fasten up VI execution speed when passing data to the display.

But the allocation dot is there, on the output of the DEREFERENCE, whether I attach an indicator or not.

[CoastalMaineBird]

The HELP text for the SHOW BUFFER ALLOCATIONS tool says this:

When you run a VI, LabVIEW might or might not use the allocated buffers to store data.  You cannot know whether LabVIEW makes a copy of the data because LabVIEW makes that decision at run time, or the VI might depend on dynamic data.

So, it might be that the DEREFERENCE operation allocates a buffer all the time (triggering the dot from the SBA tool), but never uses it unless the DVR is invalid.

In other words, a BUFFER ALLOCATION does not necessarily mean a COPY is made.

[Intaris]

Well I can say that, on RT at least, there is a measurable difference when indexing an element in an array via IPE whether the index is valid or not (i.e. if there needs to be a buffer allocated or not).

I always took this to be a no-op if the index is correct (aside from checking if the index is correct of  course).  But the performance difference tells me that there is at least some work being done if the index is incorrect.

[nathand]

---

@CoastalMaineBird wrote:

In other words, a BUFFER ALLOCATION does not necessarily mean a COPY is made.

---

This is a good point, because copying data generally takes a lot longer than allocating memory. Allocating memory - especially if it doesn't need to be cleared - should be an inexpensive operation regardless of the amount of memory requested. Copying data takes time, proportional to the amount of data to be copied.