From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

VI's memory footprint on disk

Solved!
Go to solution

Hi community,

 

I have recently made changes to a VI and it has grown by 5 MB.

I may have accidentally have saved some huge array input a default value or something similar.

The problem is: how do I find where? The vi has a rather big and nested block diagram.

All the tools I'm aware of analyse the memory footprint in RAM at runtime - I don't care for that at the moment, the memory consumption of the vi on disk is all that bothers me.

 

Any ideas?

 

Best regards,

Florian

0 Kudos
Message 1 of 21
(2,999 Views)

Well, how many controls, indicators and constants can you have? Just check them.

Else you'll have to do a search like this:

Check item size.png

/Y

 

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 2 of 21
(2,994 Views)

I don't know how many in can have - but this is the UI of a very big application and has a lot. Smiley Sad

Thanks for the snippet.

It seems that the issue is something else though. The biggest items were pictures that were already there before the changes (and they weren't even that big).

 

Any ideas how the size of the VI could have increased by 5 MB (from 7 MB to 12 MB)?

Most of what I did was of course done in sub VIs. The changes from the perspective of this UI vi should be minimal - a view exchanged sub VIs mostly.

Is there a more general approach to analysing the memory footprint of a vie on disk?

0 Kudos
Message 3 of 21
(2,982 Views)

@Florian.Ludwig wrote:

I don't know how many in can have - but this is the UI of a very big application and has a lot. Smiley Sad

Thanks for the snippet.

It seems that the issue is something else though. The biggest items were pictures that were already there before the changes (and they weren't even that big).

 

Any ideas how the size of the VI could have increased by 5 MB (from 7 MB to 12 MB)?

Most of what I did was of course done in sub VIs. The changes from the perspective of this UI vi should be minimal - a view exchanged sub VIs mostly.

Is there a more general approach to analysing the memory footprint of a vie on disk?


It sounds like a data copy of sorts, have you created a constant from a filled array? Did you manage to copy a front panel picture? Something like that has happened.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 4 of 21
(2,962 Views)

May I ask why you are so concerned about 5mb of additional file size? 

aputman
------------------
Heads up! NI has moved LabVIEW to a mandatory SaaS subscription policy, along with a big price increase. Make your voice heard.
0 Kudos
Message 5 of 21
(2,937 Views)

Good question.

Mainly because I'm concerned that I have not accidentally saved a huge picture or array into the vi and that there's something else "wrong" with it (though there isn't necessarily anything wrong with it).

I can't display the vi hierarchy of that VI - the window stays blank (may just be too big).

Lately sometimes the development system has crashed when working with that project.

The 5 MB are a 70% increase in size - I just found that suspicious, and was wondering if there was any route for diagnostics.

0 Kudos
Message 6 of 21
(2,922 Views)

You can check where the memory is located. Open VI Settings and select Memory Usage.

I assume that the rise in memory is in front panel. If so, you have to check default values. A common source of unwanted default values is to accidently (or by pure misunderstanding) Edit >> Make Current Values Default.

Please note that removing default values is, in most cases, simpliest by recreating the controls/indicators. Otherwise use property nodes to write empty values (e.g. empty array) to the control/indicator. Please note that for scalar elements, this most often does not work, which means that they still keep a default value unless you recreate the element.

If the source is the block diagram, look for huge constants.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 7 of 21
(2,913 Views)

Thanks for pointing that out.

I'll look into it. Here are the values in case someone is interested:

 

FP-O: 2675.6K

BD-O: 15425.6K

Code: 3582.9K

Data: 7837.5K

Total: ~29521.7K

 

On disk: ~12023.1K

Code complexity: 17.4

last compiled: partial comp. optimisation

0 Kudos
Message 8 of 21
(2,907 Views)

Ok, I dug up a backup of the vi made before the changes:

 

FP-O: 2628.1K

BD-O: 14998.1K

Code: 3586.6K

Data: 7837.5K

Total: ~29040.4K

 

On disk: ~7013.3K

Code complexity: 17.5

last compiled: partial comp. optimisation

 

The values seem rather similar to the new one (post above) - except for the size on disk part.

The files are in the same uncompressed folder.

Any idea what the difference might be?

 

Best regards,

Florian

0 Kudos
Message 9 of 21
(2,900 Views)

I am not sure about why this is happening. Please make the following test:

Copy the whole BD and paste it into a new VI. Save that. What is memory usage looking like for the new VI?

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
0 Kudos
Message 10 of 21
(2,893 Views)