06-09-2020 04:17 AM - edited 06-09-2020 04:19 AM
I don't like having files which are not needed to use an application. However, when you build an application from LabVIEW project it creates 2 unnecessary files: .aliases and .ini. I would like to delete them, but it causes unexpected increase of memory usage, even though LabVIEW should have all its default settings loaded first in either case.
I know that some parameters from configuration file can be modified through the project / target / build properties and a lot of them can be put manually, but in most cases it just contains a bunch of default values (according to this wiki) and the only useful parameter there enables debugging.
Environment:
Windows 8.1
LabVIEW 2018 SP1 f4
Steps to Reproduce:
Expected Result:
Memory usage stays the same regardless of configuration file.
Actual Result:
Application is using about twice as much memory without configuration file.
If you leave the file in place, even if you remove all its contents, memory usage stays the same.
Reported to NI with SR #7808973.
06-09-2020 07:42 AM
Deleting two small files that are clearly "configuration settings" (both are in .ini file format) and collectively consume < 1 kB probably means that when your execution begins and cannot find the settings it needs (for example, to know the IP of "My Computer", which is contained in the "aliases" file), it needs at run time to load routines to figure out the settings appropriate for your code.
Here's a solution to the "doubling of memory" problem -- assume that NI, who has provided an Application Builder that creates a stand-alone executable for you, "knows what it is doing" and accept having some configuration files present, along with your Executable. Most of the time, you won't need to change them, but there are applications where these settings are useful/necessary.
Bob Schor
06-09-2020 09:55 AM
Well, as I said, even if you leave a completely empty configuration file (in which case it would also need to determine settings at runtime), memory usage doesn't increase. Also the problem only relates to INI file (but even if not, why determine an IP if it defaults to "localhost"?).
If there were "routines to figure out the settings appropriate for your code", these setting won't be present in a config file. 😉
Here's how I see any (not just LabVIEW) application is dealing with its configuration files:
First of all, it needs to initialize its configuration structures with default values in case no configuration file is present or it doesn't contain all of the available settings. These default values are usually stored as constants in a code (in a data segment with a structure itself) and loaded into memory as part of an application, so we get this action "for free" as they need to be loaded anyway.
After that application checks for configuration file and replaces some default values with the settings found in it.
Speaking of somebody knowing what he's doing, I've seen enough examples of applications being sub-optimal, like leaving installers after being installed or downloading all of the available updates at once, unpacking them at once (without deleting compressed files) and applying them one by one to the same files.
I can accept having these files, but it definitely doesn't look like a correct behavior to me.
06-09-2020 10:02 AM
There's definitely a difference between "no config file" and "empty config file". In the former, I would expect LabVIEW to cook up some default settings and run with it. In the latter, I would expect LabVIEW to shrug and go with whatever is in there, even if it is "nothing".
06-09-2020 10:05 AM
@EvgenKo423 wrote:
Actual Result:
Application is using about twice as much memory without configuration file.
If you leave the file in place, even if you remove all its contents, memory usage stays the same.
"Twice" is a very fuzzy description. If the application uses 10kB, twice would be another 10kB and if the application uses 1GB, twice would be another GB. can you give more absolute numbers?
In any case, LabVIEW will create these missing files on startup and even if this costs more (because it needs to do more!), is is only once and all later startups are again cheap.
06-09-2020 11:05 AM - edited 06-09-2020 11:12 AM
Of course it's not "double" everything, but "double to base" (Run-Time Engine?).
If you build an EXE from a single VI with a bit of code and run it, it consumes ~38 MB. If you rename INI file, it consumes ~82 MB. So it's double for relatively small apps which don't process big amount of data at the same time. With bigger applications this ratio becomes smaller.
After checking with different applications it seems like memory usage always increase by ~44 MB.
(so the title is a bit click bait, but it's partly true)
Also I remember reading that in some previous versions the absence of configuration file caused applications to crash and later on its contents was re-created at every application launch or something like that, but currently they won't be re-created if you delete them.
07-15-2020 07:14 AM
NI Technical Support wrote:
You couldn't delete the folder.
(for whatever that means...)
I guess the answer is: "We have lots of more serious problems to solve and no time for your stupid nit-picking". I do believe you for sure.
07-15-2020 07:44 AM
I'm running Windows 10 Enterprise 64 bit, LabVIEW 2017 32 bit, and my memory stays the same no matter what I do with the .ini or .aliases files.
Saying "Thanks that fixed it" or "Thanks that answers my question" and not giving a Kudo or Marked Solution, is like telling your waiter they did a great job and not leaving a tip. Please, tip your waiters.
07-31-2020 03:28 PM
I also see no change in memory for any sizeable application of mine made in Labview when removing these files.
Presumably, the possible increase is menial, as is the space taken up by two, 1KB files that are used, not just for debugging purposes, but for on-the-fly behavioral changes that may be necessary without rebuilding the entire application. An empty file means the application uses defaults. A missing file means LabView may attempt to check for one. It may even mean that Labview assumes something went wrong with your build.
You removed a default file from LabView and then became bothered when the results differed from standard. I would say the results of your experiment were within reason.
08-01-2020 09:03 PM
I'd personally agree with your expectations. I wouldn't expect to see much memory growth with those files gone (even if they're recreated).
That said, the Known Issues List for LV is pretty long. If the workaround for this one is "don't delete those files or deal with 45MB which isn't a lot in 2020," it sounds like it'd be a low priority for a fix against others in that list.
That's likely why you got the response you did from support.