This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PCH [Was: Re: Target FUNCTION_{PRO,EPI}LOGUE question]


dewar@gnat.com writes:

> <<> Are you willing to give us any information about this and your PCH
>> work?  I'd really like to know more about it (without downloading a
>> separate branch and poring over it...)
>>>
> 
> It is ironic that when the GNAT project started up, one of the first
> decisions we made was that, unlike all other Ada compilers previously
> built, we would not do the equivalent of precompiling headers (in Ada
> this translates into precompiling package specs into a library). That's
> always proved a good decision for Ada.
> 
> I wonder just how much gain PCH's give you in g++, especially *after*
> installing Mark's new c++ parser ...

Funny you mention.
I went to speed test mark's parser, but it's not in good enough shape
to run the same tests i had run to get my pch benchmarks.

However, i doubt it'll make up the difference pch does.

This is because PCH really helps on template heavy code, and code
where you have a lot of stuff around but not used.  This is just about
all C++ code, except for very very simple code. Anything, for
instance, using the STL, will fall into both of these categories.
This kind of code almost always appears in headers.
So both of these cases still require you to parse it every time, unless you use PCH.
So PCH will always be a win.

I used to be in the camp of "I don't think PCH will be a big win".
It turns out that this is very wrong.
Even if you adapted your code to "one class, one header", and only
included the headers absolutely necessary, as soon as you start
reusing classes and headers, so that you use a lot of the headers, PCH
becomes a win again. 
A while back I had run some tests on things like compiling KDE with
PCH on.
As I said then, it took more time to compile 3% of something like
kdelibs (one source dir) without PCH than it did to compile all of the
sources files with PCH on.

Mark's parser would, in effect, have to be so fast that parsing
headers was instantaneous to beat out PCH.

-- 
"I'm writing a book.  I've got the page numbers done, so now I
just have to fill in the rest.
"-Steven Wright


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]