Mail Archives: cygwin/1996/11/04/22:27:33
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: root AT jacob DOT remcomp DOT fr [SMTP:root AT jacob DOT remcomp DOT fr]
>Sent: Sunday, November 03, 1996 10:54 AM
>To: gnu-win32 AT cygnus DOT com
>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
>"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
-
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 -