LVOOP memory usage

[LAVA 1.0 Content]

Hi,

I made some tests to find out how LVOOP consumes memory. I noticed something I don't really understand. It seems that LVOOP class wire consumes memory more than cluster used exactly the same way. And I don't just mean that there is a little more metadata attached. No. It seems if LabVIEW takes an extra copy of the class private data compared to that of cluster private data.

Take a look at the image below. In the first case LabVIEW doesn't make buffer copies, so 8MB memory is consumed. In the second case, LabVIEW copies the initial buffer to the cluster. That is one memory copy is made and total 16MB memory is consumed. This already is a bit weird, since instead of making a buffer copy, LabVIEW could simply change the buffer the cluster data points to. Well, it doesn't. In the third case when class constant is used, LabVIEW makes two buffer copies so that the total memory consumption increases to 24MB. This is really what I don't understand. Where does it need two copies. It seems like extremely unefficient way on using the memory. What do I not understand? EDIT: I was naturally using LabVIEW 8.2.

EDIT: I made a third test using queues as storage format for data inside an object. It seems that this is more efficient way of storing large arrays to LabVIEW objects than LabVIEW internal way of storing data. In the example below, only 16MB of memory is consumed, at least if profiler correctly profiles the memory usage of queues. Weird, I must say!

[Yair]

In the example below, only 16MB of memory is consumed, at least if profiler correctly profiles the memory usage of queues. Weird, I must say!

Actually, if I understand your code correctly, it seems that the class only holds the queue reference in this case, which would only take a few bytes. The second copy probably comes from dequeuing the data.

[LAVA 1.0 Content]

Actually, if I understand your code correctly, it seems that the class only holds the queue reference in this case, which would only take a few bytes. The second copy probably comes from dequeuing the data.

You understand me at least half correctly. What I didn't understand was why using a class without queue consumed 3x size of data.

Well I must say I don't understand why getting queue element consumes memory instead of just modifying target buffer reference so that it would point directly to queue element. I also don't understand why cluster bundle in second example consumes more memory than cluster bundle in first example since again LabVIEW could just modify cluster element buffer reference to point directly to data buffer that is "written" to the cluster. After all internally LabVIEW refers to arrays using datatype** or datatype***.

[Aristos Queue]

Bundle/Unbundle have several special inplaceness optimizations that classes did not attempt to take advantage of in this first release. Do you remember LV6.0.1 followed quickly (weeks) by 6.0.2? That was caused by a mistake in someone changing the inplaceness algorithm. It is a hard algorithm to get exactly right, and if you get it wrong, you can end up with values that change randomly as a VI executes. I decided that having a functionally correct implementation of objects in this first release was better than trying to get involved in the optimizations --- the optimizations will be added in future LV versions. Lesson one of Computer Science 101: Make it work first, then optimize later (or never). In this case, we're going to do "later."

[LAVA 1.0 Content]

Bundle/Unbundle have several special inplaceness optimizations that classes did not attempt to take advantage of in this first release.

Do you remember LV6.0.1 followed quickly (weeks) by 6.0.2?

No, I don't remember, LV 7.1. is the first version I've ever used. And I really started my LV career with LV 8.0. But good to hear that we may expect better optimization later on. Until then, I'll use queues to store my large arrays.

[Aristos Queue]

\No, I don't remember, LV 7.1. is the first version I've ever used. And I really started my LV career with LV 8.0. But good to hear that we may expect better optimization later on. Until then, I'll use queues to store my large arrays.

:laugh: Ah! That's why you're so picky! You started with the most stable version of LV ever. We've got to get you some perspective!

All joking aside: The beta period gave LV classes a pretty hard pounding and hammered out a lot of bugs. The version that finally shipped has shown itself to be fairly stable so far, but as we expected, there are problems. This was a pretty wide ranging "feature" of LabVIEW (if you can call all of the features of OO a single feature of the language!). Even as much exposure as our beta program gives to LV, there are a lot of aspects of LV, and there's no way to test all the possible system interactions. I'm actually pretty pleased with the general system stability, but the instability of any first release is what leads to "dot-zero" aversion for many customers. It's nice to have customers who find enough utility in the new stuff to put it through its paces despite the occassional hiccup.

[LAVA 1.0 Content]

:laugh: Ah! That's why you're so picky! You started with the most stable version of LV ever.

Me... picky? No, most of people are just so indifferent :laugh: I'm sure the next LV version wll be the most stable ever

Can you btw clarify why the first cluster consumes less memory than the second cluster and why enqueueing & dequeueing a buffer makes one extra copy?

[Aristos Queue]

Can you btw clarify why the first cluster consumes less memory than the second cluster and why enqueueing & dequeueing a buffer makes one extra copy?

Nope. If I understood that I might have attempted to modify the inplaceness algorithm.

There is an enlightened being whom we call Chief Architect, at whose feet we sit to better learn the secrets of inplaceness. :worship: Perhaps I will have an answer in a few years.