Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

huge .exe file size

Status
Not open for further replies.

jamesrav

Programmer
Sep 17, 2017
29
MX
I took over a VPF 9 project, the original program was about 95% complete and had some errors. The .exe file size was about 3.3 megs. I've added a few things to the program, fixed the errors ... and somewhere along the line the new compiled .exe became 15 megs. I can't recall when this occurred. What files contribute to the size of the .exe ? Do I need to pack something(s) to eliminate what I'm sure is 'empty space'. I've read that VFP had a major 'issue' with memo fields growing and growing, is that a potential cause of this? Did I inadvertently introduce something that is confusing the compiler and causing this 4x increase in .exe size? I don't think the first few compiles I did were shockingly larger than the legacy .exe, and didn't pay attention to the size until recently. I did use Unfox to decompile the legacy .exe in order to get the files to work with, but as mentioned my first new compile wasn't much larger than the 3.3 meg original.
 
I have this phenomenon ragularly with a nonvisual classlib (based on custom) with very many methods and packing the VCX helps to reduce that. Memo bloat of the Code field seems the problem, yes.

On the other side your problem could be anything indirectly adding into the project. Hopefully you have a copy/backup of the stages/versions of the project and can compare all project files and their sizes. If files were added you might look were and why, if files are more or less the same, but did grow unexpectedly, you might find the VCXes having that bloat effect.

Bye, Olaf.
 
I will investigate those possibilities. Thanks as always for your input. Fortunately even if I cannot figure it out the program runs fine and does not seem to take any longer to load.
 
I second Olaf's comment. This is quite a common phenomenon. I periodically do the following:

- Open each VCX, SCX and FRX file as a table.

- Pack it.

- Also, run Cleanup Project (from Project menu).

(Back up the entire project before doing the above).

I find that, in some cases, this can reduce the size of the EXE by as much as 80%.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads
 
>even if I cannot figure it out the program runs fine and does not seem to take any longer to load.

Well, 15MB is a small amount of data, even in RAM, and it's mainly bloat of unused memo sections included in the EXE.

It's harmless, as long as the remaining parts of the FTP don't contain something you wanted to delete and remove, but PACKing VCXes and SCXes has the positive side effect of recreating them from scratch in a clean way, if something was corrupt with the bloated data already, PACK will be the moment showing that defect, so PACKing also is an integrity check of the schematic integrity of the DBF/FPT/CDX files.

Bye, Olaf.
 
(per Olaf and Mike) I now:

1) Regularly double-click on each class (root) (...under Cls in project manager. (which opens class browser for that class))

2) Click the "Clean Up Class Library" tool-bar button for each class

3) Build the project exe once more.

Utmost blessings!
 
I had not noticed that I inadvertently Included a couple of (large) free tables in the project - I certainly don't recall intentionally doing so. I recall Olaf mentioned the symbol for Include in a prior email but that didn't occur to me. Once removed, the .exe is back to the proper size - and a little reading gave me a decent understanding of why it's ever necessary to Include a table. So I learned something as well.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top