Can I destroy an LVOOP class?

[hfettig]

Ok, here is a followup question on something I heard at NI Week: "Once an LVOOP class is loaded into memory it cannot be unloaded".

I am probably taking this completely out of context, but does that mean that every time you run code that has an object constant on the block diagram diagram a new instance is created, which then will be in memory until the program shuts down, regardless whether it is used or not?

Basically what I am wondering is the following:

I have a class called DataFile.

When I call Open an instance of the class is created, the data is loaded and parsed.

Once I am done working with the class I call Close, which empties out the private data.

However, as far as I know there is know way to destroy the actual instance, is there?

I am just wondering that although I empty the private data, every time I open a new file the instance of the old one(s) is (are) still in memory, slowly increasing my memory footprint.

I guess a way around that would be to instantiate the class outside the Open function and re-using the instance for each file.

I am used to .NET where the garbage collector comes around and frees up unused memory space. I guess there is nothing like that in LabVIEW, is there?

Cheers,

Heiko

[jdunham]

I wasn't at NI Week, but I would take that comment to mean that LabVIEW has no way of unloading the public and private VIs and CTLs which make up your class. A specific instance of a class (data on a wire) should be instantiated and garbage collected according to the same rules as normal LabVIEW data. If you put your class initializer routine in a for loop and ran it a million times, then those million copies would not persist until LabVIEW quits, but only until the data on the wires have run their course.

[Norm Kirchner]

I was there @ NI week next to you when the comment was made and in retrospect warranted a little deeper questioning.

I do believe that you can think of it as, LV is ignorant of the existence of a class until it is used thus leaving it unlocked and accessible.

But the minute the class is accessed, it locks the class and leaves it resident in memory, just like any other VI in the hierarchy.

[Aristos Queue]

QUOTE (hfettig @ Aug 19 2008, 01:19 PM)

Ok, here is a followup question on something I heard at NI Week: "Once an LVOOP class is loaded into memory it cannot be unloaded". I am probably taking this completely out of context, but does that mean that every time you run code that has an object constant on the block diagram diagram a new instance is created, which then will be in memory until the program shuts down, regardless whether it is used or not?

No. *Classes* cannot be unloaded. *Objects* are freed up just fine.

QUOTE

Basically what I am wondering is the following:

I have a class called

DataFile

.

When I call

Open

an instance of the class is created, the data is loaded and parsed.

Once I am done working with the class I call

Close

, which empties out the private data.

However, as far as I know there is no way to destroy the actual instance, is there?

I am just wondering that although I empty the private data, every time I open a new file the instance of the old one(s) is (are) still in memory, slowly increasing my memory footprint.

The preceeding list of steps makes zero sense to me. Forgive me if the following questions sound dumb, but I'm really confused.

1. Is "Open" a VI that you have written or are you meaning the Open Library Reference invoke node?
   
2. Is "Close" a VI that you have written or are you talking about the Close Reference primitive?
   
3. How the heck do you "empty out the private data"? Are you talking about just writing default values to the fields using a Bundle node?
   
4. What do you mean by "destroy the actual instance"? My answer depends upon what you mean by "destroy".
   

QUOTE

I guess a way around that would be to instantiate the class outside the Open function and re-using the instance for each file.

Huh? Are you using LV classes or one of the reference toolkits?

[hfettig]

QUOTE (Aristos Queue @ Aug 19 2008, 04:02 PM)

No. *Classes* cannot be unloaded. *Objects* are freed up just fine.

Ok, that makes sense.

QUOTE

Is "

Open

" a VI that you have written or are you meaning the Open Library Reference invoke node?

Written myself: Takes an object constant, bundles a few setup values, parses my file and has the object reference as an output.

QUOTE

Is "

Close

" a VI that you have written or are you talking about the Close Reference primitive?

How the heck do you "empty out the private data"? Are you talking about just writing default values to the fields using a Bundle node?

Written myself: Takes the object reference and yes, writing default values to the fields using a Bundle node. ("Emptying out" as in emptying out my arrays, etc.)

QUOTE

What do you mean by "destroy the actual instance"? My answer depends upon what you mean by "destroy". Huh? Are you using

LV

classes or one of the reference toolkits?

I think jdunham cleared that up for me in his reply. I forgot that this is ByValue we are talking about. So as soon as the wire ends, the content is gone, i.e. destroyed (or more likely garbage collected shortly thereafter). I got a little confused since inside this class I am using the OpenG dictionary type, which uses OpenGOOP, which is ByReference, where you actually have to destroy the instance, i.e. reference, when you are done with it.

[Aristos Queue]

Ah. Your reply makes things make sense. Thank you.

QUOTE (hfettig @ Aug 19 2008, 06:30 PM)

I think jdunham cleared that up for me in his reply.

I was writing my reply when his was posted and I didn't see it until I sumitted. :-)

[jdunham]

QUOTE (Aristos Queue @ Aug 19 2008, 04:36 PM)

Ah. Your reply makes things make sense. Thank you.

QUOTE (hfettig @ Aug 19 2008, 04:30 PM)

I think jdunham cleared that up for me in his reply.

I was writing my reply when his was posted and I didn't see it until I sumitted. :-)

Wow, I don't usually slip in there first.

BTW, wouldn't it be great to have a native associative array or hash table in LabVIEW? It could be just like the OpenG dictionary but with super-fast lookups and native polymorphism. It would fit in really well with the queue and notifier palettes. Just an idea (whose time has come, and is maybe a bit overdue).

[Aristos Queue]

QUOTE (jdunham @ Aug 19 2008, 08:10 PM)

BTW, wouldn't it be great to have a native associative array or hash table in LabVIEW? It could be just like the OpenG dictionary but with super-fast lookups and native polymorphism. It would fit in really well with the queue and notifier palettes. Just an idea (whose time has come, and is maybe a bit overdue).

Ah, irony...

Let me tell you a story... there once was a LV developer who had as his first assignment the task of creating the queue and the notifier primitives. And, at the same time, this developer created a palette of associative map primitives. Very fast, parallel safe, etc, modeled on the same API as the queues and notifiers. The queue and notifier primitives went into LV. The associative map primitives did not. Why? Because customer feedback said that while queues and notifiers are used for communication, and therefore are appropriate places for reference data types, an associative map should be a dataflow type. Who would want to use a map by reference?

That was eight years ago. This developer went on to develop LV classes, propelled to some degree by wanting a structure in LV that could express the associative map that had been implemented all those years ago. And now, today, there are two very different map implementations:

http://forums.lavag.org/Map-implemented-wi...r-85-t8914.html

and

http://www.ni.com/labs/ (search for "LabVIEW Generic Container Map")<h4></h4>

[jdunham]

QUOTE (Aristos Queue @ Aug 19 2008, 08:21 PM)

Because customer feedback said that while queues and notifiers are used for communication, and therefore are appropriate places for reference data types, an associative map should be a dataflow type. Who would want to use a map by reference?

Sometimes I think NI is listening to the wrong customers.

QUOTE (Aristos Queue @ Aug 19 2008, 08:21 PM)

That was eight years ago. This developer went on to develop

LV

classes, propelled to some degree by wanting a structure in

LV

that could express the associative map that had been implemented all those years ago. And now, today, there are two very different map implementations:

and

(search for "LabVIEW Generic Container Map")<h4></h4>

Well, if you run into that developer again , please tell him that eight years is a long time to wait, and we're still waiting (since the first one has a performance bug and the second one is languishing in pre-release status).

Lest anyone think I am totally hijacking the thread, I am assuming that Heiko is implementing some kind of associative array since that's what Open G dictionary is for. At some point after so many people are reinventing the wheel, I hope we can get to a native implementation with a great API and fast performance.

Thanks AQ for your efforts to move this forward!