Controlling the size of an .exe file

[AndrewMozley]

Over time a compiled VFP application may expand in size. If there are more facilities, that is fine. One example currently has 4.4MB.

I have occasionally examined code to remove functions which are no longer used, and also examined .vcx/vct class library files to see whether they have deleted records. In that case, removing DELETED records can help.

As far as I know, most of the space in the .exe file is made up of the code from my forms and classes; I have not usually included the report layouts (.frx/frt) into the .exe file - they are kept in a different folder for each installation.

Do other users have any way of checking for ‘bloat’, particularly deleted records in their .scx and .vcx libraries? There are quite a lot of files, so it would be nice to have a tool to check all the files in a folder.

Thanks. Andrew

 

[tomk3]

Hello,

from time to time I use and pack the .scx,...
They are just .dbf /.fpt with another extension.
And I use refox for crypting and packing the exe.

regards
tom

 

[Nigel Gomm]

Andrew,

i have this before each build

SELECT 0 
USE myproj.pjx
SCAN FOR INLIST(TYPE,'V','K','R')
	TRY
		m.lcname = ALLTRIM(name)
		IF TYPE = 'V'
			CLEAR CLASSLIB (m.lcname)
		ENDIF
		SELECT 0
		USE (m.lcname) EXCLUSIVE
		PACK
		use
	CATCH TO oe
	WAIT WINDOW m.lcname+":"+oe.message+"@"+TRANSFORM(oe.lineno) TIMEOUT 3
	ENDTRY
ENDSCAN
use

it helps a bit. And there is 'clean up project' in the project menu which packs the .pjx file itself.

n

 

[AndrewMozley]

Thank you Nigel. That saved about 6K. Only a modest economy, but it all helps. What does it do?

 

[Nigel Gomm]

Andrew,

it just packs each (vcx/scx/frx) table - gets rid of the deleted records for you.

you can do the project cleanup programmatically with

MODIFY PROJECT myproj NOWAIT NOSHOW
_VFP.ACTIVEPROJECT.Cleanup()
_VFP.ACTIVEPROJECT.CLOSE()

and losing the debug info will reduce the .exe size considerably.... but makes your error reporting & audit trail less useful (program line numbers esp)

n

 

[Gerrit Broekhuis]

Hi Andrew,

A 4.4MB executable (without data!) looks quite OK to me. I use for example XFRX to create reports in various formats, and this adds about 1MB to the executable. My .EXE files are mostly between 4 and 10 MB.

Of course you could add some code to create your own DLL that becomes part of your software solution. I haven’t tried this yet, as the file size is no problem whatsoever for modern systems. Speed is no issue either.

Regards, Gerrit

 

[Mike Lewis]

Andrew,

As well as all the things that have already been mentioned, I sometimes do a clean-up of the project (open the project -> Project menu -> Cleanup Project). It seems to make a difference most of the time.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Mike Lewis]

Also, go to Project -> Project Information, then check that "Debug info" is not ticked. This will definitely reduce the size of the EXE, but at the expense of not seeing your code or line numbers in your error handler.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Gerrit Broekhuis]

Hi,

I have a Project Cleanup (before creating a new build) in my default projecthook class, included in every project. Also when closing the project, it’s backupped.

Regards, Gerrit

 

[Mike Lewis]

Andrew,

Have you had a chance to try any of the above suggestions - apart from the 6 KB you saved by packing the various forms, etc? It would be interesting to know if you reached any conclusion.

Regarding my suggestion of removing the Debug Info from the project, I remembered that we had a discussion about this some months ago. I did a little test, and found that, unticking "Debug Info" led to a reduction of about one third in the size of a small EXE. (See my post time-stamped "20 Oct 20 12:56" in thread184-1806597.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Gerrit Broekhuis]

Mike,

As you already wrote yourself, unticking “Debug Info” has quite some effects on error logging and messaging.

We have a lengthy errorhandling routine, that logs lots of things and we would never give up getting adequate error information, just for a smaller .exe file. The errorhandling has proven to be a vital element in our software for tracking and fixing errors. In the end we will get better software, with less errors.

You will know that users are allways able to do things you never thought about, so we would never stop using our errorhandling as informative as it is now.

Regards, Gerrit

 

[Mike Lewis]

Gerrit, of course you are right. It is a simple trade-off: debugging information vs. smaller EXE size. I am not arguing for one or the other. But I thought it right to give Andrew the option to consider.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[GriffMG]

I run a routine before every compiling that does a tidy and removes paths from data environments, some printer settings etc.

That certainly, normally, keeps the resultant exe size down - except where I'm using the .exe to carry a binary file for
implanting on the client machines - such as a .dll or a word / excel file

Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[AndrewMozley]

Thank you Griff, Mike, Gerrit and Nigel.

That was useful information about 'normal' exe sizes for a fairly comprehensive application (mine has about 100 forms including file maintenance, transaction entry, reports, enquiries &c).

I take your point about possibly omitting debug information. But I make lots of errors, so I feel that I ought to leave the debug available for the error reports!

I ran the Cleanup(). I think I must have already gone through my forms (.scx/sct) and classes (.vcx/vct), packing them to remove deleted records, so I did not get any further saving there.

One thing I did notice, is that a fair few controls on my data entry forms have properties defined which are the default values. For example several text boxes on columns in my grids have the Forecolor defined as RGB(0,0,0) and the BackColor as RGB(255,255,255) - which is the default. I don't remember setting them all by hand. But it would hardly be worth the trouble to go through and edit these.

Andrew

 

[Mike Lewis]

Andrew,

Re your point about properties that have been changed to their default values. I can see that this would add a bit of overhead to the EXE, given that some code must exist somewhere to actually set those values. That's true even if you change the value at design time. My guess is that the extra space would be pretty negligible, and almost certainly not worth the effort of trying to deal with it.

That said, I did wonder if it was possible to write a program that would do the job for you. It would need to loop through all the properties of every object, which you could do using AMEMBERS(). Then, for each property, check that it has changed from the default, using SYS(2019). And if so,call ResetToDefault() to change it back.

The only snag is that that would reset all your properties, including those that you intended to change (which would probably be the large majority of them). What you need is a function that retrieves the default value, so that you can compare it to the existing (changed) value. I haven't been able to find a function that does that.

Does anyone have any suggestions? (I stress that this is probably no more than an intellectual exercise. As I mentioned above, the saving would probably be very small. But it might be interesting to follow it up.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[TamarGranor]

There's a Thor tool that tells you about properties that are actively set to the default value. Thor Tools | Parent Classes | Compare with Parent Class.

Of course, running through every object and doing that would be tedious, but I wonder if the code for that tool could be adapted to spin through a whole list and collect the data.

Tamar

 

[Chris Miller]

5 MB isn't very much I wouldn't worry about it.

But you could save 50% and more.

The debug information in an EXE mainly is the source code, it enables you to get the code of the line triggering the error, but without it, you still get the line number.

The only problem is continuing development on the project often shifts line numbers. So actual source code helps to reidentify the line. But that problem can be solved with a source code control system. Archive the version of the project as it is directly after a build and the line numbers of error reporting will still be valid in this archived version of the build, while you can continue development on the main branch.

How is it possible to get rid of the source code? It's the basis of the EXE, isn't it? Well, you do two passes, once with source code and then after removing source code and packing files without 'recompile all'.

Naturally, all this should be done on a copy of the project and automated as you still need your code to continue development. This means you need to define a build process doing the project copy, archiving it with a version control system, and finally making the modifications for the second pass build without source code.

Even when you decide to keep code in the EXE you can remove comment lines, they never trigger an error but still become part of the EXE.

Chriss