Memory managment

[EricC.]

Where LabVIEW close a VI it does not free the memory automatically. This should allow the VI to reopen soon.
For large projects or multiple projects open at the same time, this feature is very annoying. More and more memory is consumed and the only way to release is to close LabVIEW.
It should be possible to force the mode of operation within the parameters of LabVIEW.
[X] Free memory when a VI / Project is closed
[  ] Maintain a copy of the VI in memory to improve performance at the reopening.
In the second case, it would be useful to have a command in the menu of LabVIEW to force the timely release of memory.

[Mr.Mike]

Eric C,

I'm not entirely sure I understand what you're talking about.  Are you talking about a memory leak (e.g. a slow rise in the amount of memory LabVIEW uses) or LabVIEW keeping VIs open when other VIs that refer to them are open?

If it's a memory leak, there usually isn't an easy fix.  A memory leak is caused when we request memory but forget to return it.  These are pretty hard to track down, so it's not a matter of there being an option to not do this: it's a bug.  If you close everything and get back to the Getting Started Window and LabVIEW's memory usage is still high, it's a memory leak.  Please contact your customer service rep and report the bug.  We need very detailed information on what you did that caused the problem.

On the other hand, sometimes we keep a VI in memory because another VI or project item refers to it.  This is done because the VI might be changed by related item (e.g. when you change the class cluster, all of the VIs which belong to that class are updated).  If we were to take it out of memory, we'd need to save it to disk.  If we saved to disk, then you undid your changes, we'd have a disconnect between what's saved in one file and what's saved in another file.  We keep it in memory so that it can all be saved together.

Please explain in more detail what you mean.

[altenbach]

Are you taking about memory use during development (programming session) or during a run?

If you are talking about execution, the "request deallocation" tool might (or might not!) help.

[AristosQueue (NI)]

> Where LabVIEW close a VI it does not free the memory automatically 

You're going to need to post a much more detailed explanation of what you are talking about. Your comments ambiguously talk about many different actions:

1. Closing a VI's panel

2. Closing a VI reference

3. a VI unloading from LabVIEW

4. A VI hierarchy going idle after finishing execution

5. Compacting the dataspace of a single VI in a still-running hierarchy at the end of a particular invocation

Please clarify which of these operations you're having difficulty with.

[GregR]

Perhaps we can avoid all the "what does closing a VI mean" discussion. The idea also mentioned closing a project. We can pretty clearly say that when you close a project all the memory for that project and its VIs is freed. So I would say we already do what this idea suggests.

The problem is simply perception. If you look at the memory size for the LabVIEW process, load a bunch of VIs from a project, close the project and look again at the memory size for the LabVIEW process, then you will see that LabVIEW has grown. This is not because we "leaked" anything. There are a couple of reasons for this growth.

To speed up launch time LabVIEW lazily loads and caches a lot of information. This includes palettes, plugins for the project system and many others. We do not unload these when you close a project. We assume that since you didn't quit LabVIEW you are probably going to open something else and we would just be loading them again anyway.

The other big reason is actually common to all applications. The operating system allocates memory in pages. Applications almost always have another memory manager that handles making smaller allocations out of these pages. In order for the memory manager to free a page back to the operating system all the small allocations from the page must have been freed. This means a single allocation of 1 byte could look like a much larger allocation to the operating system.

These two combined mean it is expected for LabVIEW's memory usage to be higher after closing a project then it was before you opened it.

[EricC.]

I can understand that LV I need to memorize some information,
 but here's an example:
 - Launch of LV: Memory used: 118 MB
 - Opening of the project: Memory used: 322 MB
 - Ouverutre the 'Main ' (Without running) : Memory used: 450 MB
 - Close and return to the start screen: Memory used: 387 MB

 I read the memory on the LV process in Windows Task Manager.

The difference between the two splash screens is 269Mo

I do not think LV are stored 269 MB of data.
That's a lot of data

Nota : My project contains 4050 VIs (VI Lib included)

[AristosQueue (NI)]

Well, you opened a project. That means we probably loaded all the project providers (I'm guessing that with 4050 VIs, you probably use every project feature somewhere ). That's 41MB on disk, and the VIs are saved compressed, so that's a good chunk of your size. That's just the LV installation with no toolkits or modules. You might have additional toolkits installed, which may have added their own providers.

The palettes load in the background of LabVIEW, so when you first launch LabVIEW, hit ctrl+space to force the palettes to finish loading, and use that as your base measure for LabVIEW. That's probably another couple meg, depending upon the size of your user.lib.

All in all, 269 MB isn't unexpected.

[Darren]

Any idea that has not received any kudos within a year after posting will be automatically declined.