FP memory usage when minimized depends on how minimized?

[Matthew_Williams]

Within the 8.2.1 development environment, it seems that there is a difference in
the memory footprint of a vi, depending on whether it was minimized using the
windows title bar button vs. the LV FP.state property.

If this vi is minimized with the window button, the memory (briefly) drops down to
~ 2MB, then bumps back up a bit.  If it is minimized with the FP.state property, the
memory used does not change.  In either case, if the window is restored by clicking
on the status bar, consumption is ~ 4-20MB.

Is it correct that the brief, lower memory size represents the 'non-display' requirement
of the vi, and the bump back up represents the front panel ('display') requirement
being reloaded, even though it is not displayed?

Why do the two methods of minimization differ in their memory requirement, or why
does the FP.state minimization approach not reduce memory like the windows
button does?

Most importantly, is there a programmatic way to minimize the window _and_
get the lower memory footprint, preferrably keeping the lower memory usage?

If I have completely mis-understood something, that is fine too 🙂

Thanks for any input.

Matt

[johnsold]

Matt,

This may be a Windows thing. When I run your VI in LV 8.5 on my Mac, I see no changes in LV's memory requirement whether the VI is minimized either way and whether LV itself is hidden or showing. The profile tool show the VI only requires 3.33 KB of memory, but won't update while it is running, so that does not provide any clues.

It is also interesting that the button does not "unlatch" until the stop button is pressed, even if the terminal is moved inside the event case.

Lynn

[Matthew_Williams]

Thanks for the input, Lynn.  I kind of expect this is a windows specific thing.

I have also noticed that memory usage decreases significantly if I close all of
the project windows, which is also curious.  I wouldn't expect a project window
to require > 10MB, which kind of makes me think there is a lot more going on
than 'show-don't show' this list of files.

Sorry, I forgot to mention that I am looking at the OS memory requirements
throughout.  I am working on an application that will run as a service, so
if I can minimize memory requirements by specifically manipulating the
FP, that would be a good thing.

Matt

[Ben]

Hi Matt,

I can't explain what you have observed but would like to remind you of something I often over-look, "The un-do buffer" has to be saved somewhere.

I admit this may be a tangent.

Ben

[Matthew_Williams]

Hi Ben.  Thanks for the input.

I took ran the vi, FP only open, confirmed the memory drop and bump back.

Then I moved one of the buttons and repeated the test w/o saving.

Memory looked approximately the same across both cases, so my guess is
that the undo-buffer is preserved within whatever that smallest memory footprint is.

I guess I'll have to build an executable and test there; that is what really matters anyway.

I'll post back.

Matt

[Matthew_Williams]

It looks like a built .exe has the same memory footprint pattern.  Very interesting.

Matt

[Matthew_Williams]

Another clue:  If I defer FP updates when programatically minimizing the vi, memory footprint goes up and stays.

Minimizing by clicking the task bar has the same effect as when using the minimize button (kind of makes sense).

Sample vi OS memory footpring:
running ~ 5MB
OS minimize: drops to ~1.5MB, then back up to ~5MB within 10 seconds or so
LV FP.state minimize: stays about 5MB, except if defer FP updates is enabled, then jumps to ~7MB

More thinking required...

Matt

[Navne]

I have a bold spot on my head form trying to crack this problem as this also applies to the web server - however.... 

The answer is here: 

http://forums.ni.com/ni/board/message?board.id=170&message.id=474974&requireLogin=False