Subject: RE: Speeding compilations
From: [email-masked] (Scott Field)

4 Nov 1996 22:27:33 -0800
Sender: [email-masked]
Approved: [email-masked]
Distribution: cygnus
Message-ID: <c=US%a=_%p=msft%l=[email-masked]>
Original-To: "[email-masked]'" <[email-masked]>,
        "[email-masked]'" <[email-masked]>
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.56
Encoding: 98 TEXT
Original-Sender: [email-masked]

Try:
#define WIN32_LEAN_AND_MEAN
#include <windows.h>

Works well for most projects, and much less work than making header file
edits.

>-----Original Message-----
>From:	[email-masked] [SMTP:[email-masked]]
>Sent:	Sunday, November 03, 1996 10:54 AM
>To:	[email-masked]
>Subject:	Speeding compilations
>
>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
>"[email-masked]" with one line of text: "help".
-
For help on using this list, send a message to
"[email-masked]" with one line of text: "help".