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: Content-Type: text Original-To: gnu-win32 AT cygnus DOT com Content-Length: 3128 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 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".