From mboxrd@z Thu Jan 1 00:00:00 1970 From: Noel Yap To: Neil Booth Cc: Stan Shebs , Mike Stump , gcc@gcc.gnu.org Subject: Re: Faster compilation speed Date: Sat, 10 Aug 2002 20:27:00 -0000 Message-id: <20020811032757.81551.qmail@web21410.mail.yahoo.com> References: <20020810231513.GA32213@daikokuya.co.uk> X-SW-Source: 2002-08/msg00614.html --- Neil Booth wrote: > Noel Yap wrote:- > > > The study also indicates that having #include's > within > > header files is the largest contributor to the > problem > > (since nested #include's would increase the number > of > > file accesses combinatorially). > > See below for why this isn't true for most compilers > now. > > > As another indication that the conclusion is true, > > Lakos added guards around the #include lines > > themselves and found compile times to dramatically > > decrease. For example: > > #if header_h > > # include > > #endif > > This isn't the case with GCC. I hope you're aware > of that. > The first time GCC reads it remembers if > it had > header guards. If it's ever asked to #include it > again, > it checks if the guard is defined, and doesn't do > anything. > The file's contents are also not cached if it has > header > guards, on the assumption that the contents are > unlikely to > be of interest in the future. > > In other words, this kind of #include protection is > ugly and > pointless (and possibly error-prone, though that > would tend > to be immediately obvious). Most compilers now > implement > this optimization, but 5 or 6 years ago this wasn't > the case. > I think GCC was one of the first. I stand corrected. (I'm assuming gcc doesn't do this in cases where the header guard might have side effects or if there's a matching #else for the #ifndef). Do you think precompiled headers would help build speed across several compiles since it would be another source to eliminate repeated file opens? Thanks, Noel __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com