memory page seems to ignore diagram constants

[altenbach]

Looking at the VI posted here, there is a 2D 250x250 DBL array (~500kB) diagram constant on the block diagram. That's quite a bit of data!

However if we go to "VI properties...memory usage" (see image), the size of that diagram constant is only reflected in the size on disk. I would expect it to be part of the "block Diagram Objects" or "Data", but these values are very small.

 

Are diagram constants not counted as part of any listed group? Why not?

[Ben]

If you are talking about the image from post #5... is that code folded so it only has to exist on disk?

Ben

[altenbach]

No, I am talking about the code attached to post #4. There is no code, all the diagram contains is the big array diagram constant.

I would think that folded code in general needs to be loaded in memory too, its data is used at execution time.

Here the values are only useful at edit time. But how else can we look at the values on the diagram? It is a diagram object and it is in memory because there is no disk IO involved when we scroll the array. Why isn't the "diagram objects" value larger?

And yes, the compiled "code" is probably small, because of compiler optimization, so it may not exist in the compiled code. But also note that debugging is not disabled, for example.

I guess it is a matter how these various categories are defined, but IMHO, it does not add up. 😉

[Ben]

That data is stored only on disk becuase it is not used. Create an indicator and the memory numbers will look more like what you expect. The indicator requires real data so it will become part of the diagram.

Just my 2 cents,

Ben

[Ben]

Intersting thou...

Drop a new 2d-matrix and set the index to 10,000 X 10,000 and you can not enter a "1" in the top left cell. Is labVIEW trying to protect me from myself?

Ben

[Henrik_Volkers]

Just tried with a 2D DBL Control

starting with a 1 at 0,0 ... 🙂

add a 1 at 50,50 ... OK... 🙂

add 1 at 500,500 ... OK... 🙂

add 1 at 5000,5000 ... Out of memory 😞

.

.

.

add 1 at 4957, 4957 OK 😄

but 10000,10000 not possible ...

OK... with my arry at 4957x4957 I tried Make current values default and got an out of memory again

Need to claim more memory for my PC 😄 😄

Edit: LV2012,W7 32bit

[GerdW]

Hi,

creating a 2D DBL array, putting a "1" into element [5000, 5000] is possible using LV2011SP1-32bit on Win7-64bit. Saving this VI, then checking memory usage: 11.8k block diagram objects, 18.8k total, ~194k on disk. So the 2D array with 5000*5000*8byte=190MiB is compressed to just 12k…

Now setting element [6000, 6000] to 1: 12.3k block diagram objects, ~20k total, ~277k on disk.

3rd attempt: setting element [7000, 7000] to one seems possible. Trying to save the VI then results in an error message: "End of file detected. Cannot save VI. LabVIEW-save error code 5: BD-Heap" (rough translation from German).

[altenbach]

Yes, these are slightly different problems.

Not only does it need ~200MB of memory, it needs 200MB of contiguous memory, which is harder to get. It also needs to format the entire array for display on the diagram constant. Then, as soon as you wire from it, it needs to make a data copy for the first operation, because it cannot touch the allocated diagram constant, which needs to remain in place unchanged. That data buffer cannot be re-used! As soon as you would add an indicator, it would also need two more copies of the data (transfer buffer and indicator, etc.). It is not surprising that there is a certain limit, because a single diagram constant that would fill all memory could not be used for anything.

VIs are internally compressed on disk (for many LabVIEW versions already), so it is not surprising that a huge array filled with mosty zeroes is small because it can be described in a few bytes. If you would fill the diagram constant with random binary data, it would compress significantly less.

It is not a good idea in general to have huge diagram constants with real data on the diagram (just try it!). LabVIEW becomes very sluggish or even unresponsive for extended amounts of time when you try to load the VI.

The mystery remains why the original VI does not list the diagram constant under block diagram objects, which it is(!), IMHO. 😄

Just guessing and thinking out loud. Some of my statements might not be entirely correct because I don't know enough about the inner workings of the compiler.

[Ben]

Agreed on most of what you said but going back to your original question...

Until that contant is used for anything it may as well be a jpg pasted into the diagram which I would not expect to affect the size of the code. VI size yes, machine code size, no.

Ben

[altenbach]

---

@Ben wrote:

Until that contant is used for anything it may as well be a jpg pasted into the diagram which I would not expect to affect the size of the code. VI size yes, machine code size, no.

---

You cannot scroll a jpg and inspect 100k+ values (or change the index). There is massive amounts of information there.

At edit time, all array data needs to be in memory somewhere. Maybe it is just in it's own, unlisted category.

Personally, I would count it as "diagram object", but I don't know the NI definition of that term. 😄