From:	root AT jacob DOT remcomp DOT fr (root)
Subject:	Speeding compilations
3 Nov 1996 12:59:57 -0800 :
Sender:	daemon AT cygnus DOT com
Approved:	cygnus DOT gnu-win32 AT cygnus DOT com
Distribution:	cygnus
Message-ID:	<m0vK7gG-000ALAC.cygnus.gnu-win32@jacob.remcomp.fr>
Original-To:	gnu-win32 AT cygnus DOT com
Original-Sender:	owner-gnu-win32 AT cygnus DOT com

I have modified Scott's header files to speed up the compiles in lcc. Since
this is of general interest (I suppose) I post the modifications to this
group.

In general I have added countless functions that were missing, small errors
typos, etc etc. This is hard work, but not very interesting.

More interesting is the fact that for EVERY compilation of a windows program,
the compiler has to process all header files. Since with modern CPUS the
compilation is probably I/O bound, i.e. limited by the speed of the hard disk,
it is important to keep the header files small.

Normally, when I use MSVC header files (version 4.0), the program

#include <windows.h>

will make the compiler read 2,182,075 bytes...

Using the modified files from Scott's distribution, this comes down to
529,683 bytes 'only'.

Since neither lcc nor gcc have pre-compiled header files, I think it is
worth to do something about this...

My modifications are simple. For instance the declaration

WINBOOL
STDCALL
HeapValidate(
             HANDLE hHeap,
             DWORD dwFlags,
             LPCVOID lpMem
             );

becomes:

WINBOOL STDCALL HeapValidate(HANDLE,DWORD,LPCVOID);

From 128 bytes, the same declaration becomes only 50 bytes, an improvement of
more than 100%, better actually than LZH!

More, I elmiminate all identifiers in this prototype, leaving
the naked types. This means less characters, less work for the compiler, since
the preprocessor is not going to see them, pass them over after
verifying that they are not macros, the parser in the compiler later,
is not going to see this identifiers, etc.

At each line the compiler has to do some housekeeping to keep the diagnostics
in phase with the currently parsed line. This is avoided by keeping the whole
prototype in the same line.

This optimizations are even more important for gcc than lcc, since 
lcc has an integrated pre-processor that will output directly to the 
compiler without touching the disk. 
GCC uses the more traditional approach of an intermediate file, so
that each character has to be read by the pre-processor, written to the
intermediate file, and read from there by the compiler proper. 3 I/Os instead
of one! Keeping header files small would surely improve the speed of gcc...

Of course disk caches play an important role, and can be argued that the system 
will cache the whole file anyway. Perhaps, but a smaller file will be cached 
more easily. 

I eliminated all comments, license agreements etc. I think that is not 
necessary that the compiler reads the license agreement at each compilation,
since it will probably agree with everything :-) comments are just ignored!
The license agreement has been moved to a file in the same directory, and
only a small pointer was left in the header files proper.

I think that we have been mislead by the fact that header files are ascii
files, and we have forgotten that each byte that we put in there will 
increase the compilation time, specially in slow machines.


-- 
Jacob Navia	Logiciels/Informatique
41 rue Maurice Ravel			Tel (1) 48.23.51.44
93430 Villetaneuse 			Fax (1) 48.23.95.39
France
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".

- Raw text -