Precompiled headers?

Precompiled headers?

[Thomas Wagner]

Does egcs allow for precompiling header files?

-Tom
--
honus+@cmu.edu, Principal Software Engineer, the NetBill project
Information Networking Institute, Carnegie Mellon University
"Always there's that space between what you feel and what you do,
   and in that gap all human sadness lies." -George Rodrigue

Precompiled headers and General Parsing of Header File

[Kevin Atkinson]

Thomas Wagner wrote:
> 
> Does egcs allow for precompiling header files?

I have been meaning to suggest that for a long time.  I am glad you brought it
up.

Also have you considered the idea of not fully parsing the header files with
template information in it ot help speed up compiling of code that uses the
STL.  

By not fully parsing the header file I mean skipping over the class/functions
definitions.  For example:

template <class X>
void long_func (X a, X b) {
  /* very vert long defination
   ...
   ...
   ...
   ...
   ...
  */
}

When reading the above code for the first time the compiler will just take the
inner code and put it into one large block with out parsing it at all (unless
to check for nested {} and } in quotes).

It will then be parsed only when it is instantiated.

This to me would seam to save a lot of time when a lot of unused templates are
included in the header file like with SGI STL.

This idea could even be extended to class information because if the class
never gets called there is no need to know what members it has.

So what do you think of that idea.  Would it help speed up compile time?

Thanks Again.

Kevin Atkinson

Re: Precompiled headers and General Parsing of Header File

[Noel Yap]

Kevin Atkinson wrote:
> ...
> template <class X>
> void long_func (X a, X b) {
>   /* very vert long defination
>    ...
>    ...
>    ...
>    ...
>    ...
>   */
> }
> 
> When reading the above code for the first time the compiler will just take the
> inner code and put it into one large block with out parsing it at all (unless
> to check for nested {} and } in quotes).
> 
> It will then be parsed only when it is instantiated.
> 
> This to me would seam to save a lot of time when a lot of unused templates are
> included in the header file like with SGI STL.

It'll also place any compiler warnings/errors where the template is
used, not where it's defined.  I would probably want warnings/errors to
be signalled where the template is being used and have it point back to
where it's defined (like any conflicting definitions of
variables/functions).

Noel

Re: Precompiled headers and General Parsing of Header File

[Jason Merrill]

>>>>> Kevin Atkinson <kevina@clark.net> writes:

> Also have you considered the idea of not fully parsing the header files
> with template information in it ot help speed up compiling of code that
> uses the STL.

> By not fully parsing the header file I mean skipping over the
> class/functions definitions.  For example:

Actually, g++ used to work this way.  I changed that in '96 so that
templates would actually work properly; trying to feed stuff back to the
parser is very tricky with a non-reentrant parser, and the semantics are
wrong anyway.  The standard specifies that names which do not depend on a
template argument are bound at the point of the template definition.

Jason

Re: Precompiled headers and General Parsing of Header File

[Kevin Atkinson]

Jason Merrill wrote:
> 
> >>>>> Kevin Atkinson <kevina@clark.net> writes:
> 
> > Also have you considered the idea of not fully parsing the header files
> > with template information in it ot help speed up compiling of code that
> > uses the STL.
> 
> > By not fully parsing the header file I mean skipping over the
> > class/functions definitions.  For example:
> 
> Actually, g++ used to work this way.  I changed that in '96 so that
> templates would actually work properly; trying to feed stuff back to the
> parser is very tricky with a non-reentrant parser, and the semantics are
> wrong anyway.  The standard specifies that names which do not depend on a
> template argument are bound at the point of the template definition.
> 
Hu! You really lost me here.  Could you elaborate.

I understand that not parsing template definitions also means not catching
syntax errors until they are instantiated, however to me that is a minor
drawback which can easily be fixed with a command line option...

Templates are a beautiful thing, however in reality they are very difficult to
both implement correctly and efficiently.

Truefully I find the compile time for code that uses the STL ridiculously slow
and there seams to me that they has got to be a way to speed things up by a
factor of 1/2 or more...

Re: Precompiled headers and General Parsing of Header File

[Jason Merrill]

>>>>> Kevin Atkinson <kevina@clark.net> writes:

> Jason Merrill wrote:

>> >>>>> Kevin Atkinson <kevina@clark.net> writes:

>> > Also have you considered the idea of not fully parsing the header files
>> > with template information in it ot help speed up compiling of code that
>> > uses the STL.
>> 
>> > By not fully parsing the header file I mean skipping over the
>> > class/functions definitions.  For example:

>> Actually, g++ used to work this way.  I changed that in '96 so that
>> templates would actually work properly; trying to feed stuff back to the
>> parser is very tricky with a non-reentrant parser, and the semantics are
>> wrong anyway.  The standard specifies that names which do not depend on a
>> template argument are bound at the point of the template definition.

> Hu! You really lost me here.  Could you elaborate.

  void f (int);

  template <class T>
  void g (T)
  {
    f (1.0);
  }

  void f (double);

  main ()
  {
    g (24);
  }

Here, the call to f in g is bound immediately to f(int), since 1.0 does not
depend on T, even though at g's point of instantiation there is a better
match.  g++ actually doesn't get this right yet, but it's why we have to
parse templates immediately.

> I understand that not parsing template definitions also means not catching
> syntax errors until they are instantiated, however to me that is a minor
> drawback which can easily be fixed with a command line option...

That way lies madness.  There will only be one implementation of templates
in the compiler.

> Templates are a beautiful thing, however in reality they are very
> difficult to both implement correctly and efficiently.

Yep.

> Truefully I find the compile time for code that uses the STL ridiculously
> slow and there seams to me that they has got to be a way to speed things
> up by a factor of 1/2 or more...

Try profiling the compiler to see where it's spending all of its time.

Jason

Re: Precompiled headers and General Parsing of Header File

[Carlo Wood]

| > Does egcs allow for precompiling header files?
| 
| I have been meaning to suggest that for a long time.  I am glad you brought it
| up.
[..snip..]

For me, the Bad Thing(tm) about templates is that they need
to be included in a LOT of *different* source.cc files, and
are compiled every time again :(.

What would speed up compilation enormously is when somehow
a headerfile that is included in many different source
files is only compiled once (if possible).

I've been thinking about this for some time (I'm writing
a C++ parser myself, with as main reason that I need
a working indent and want to have something that generates
docs from my source) and I came up with the following idea:

When parsing a header file, a MACRO "signature" of the
headerfile should be constructed: Which macro's are used
in #if, #ifdef and #elif and what are their values at
the entry of the headerfile.  Then, while compiling
source.cc, a header.o "database" should be generated
that includes this signature.  The same header.o then
can be used for other source files when they #include
the header.h with the same macro "signature".

The recursive #includes of headerfiles is something that
makes me uncertain that this can ever work satisfactory
however.

---

There is something else that makes me think however...
It seemed to me that I could accomplish the same
by using -fno-implicit-templates and instantiating
templates only once, in a single source file.
(I automated the generation of the instantiations,
and it worked with gcc-2.7.x.  It does NOT work with
gcc-2.8.x and egcs, and I believe these to be broken).
But, the speed up of this was VERY little. Almost nothing
(maybe 10% faster).
So, perhaps you're right and most of the time is spend
in parsing?.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: Precompiled headers and General Parsing of Header File

[Kevin Atkinson]

Jason Merrill wrote:
> 
> >>>>> Kevin Atkinson <kevina@clark.net> writes:
> 
> > Jason Merrill wrote:
> 
> >> >>>>> Kevin Atkinson <kevina@clark.net> writes:
> 
> >> > Also have you considered the idea of not fully parsing the header files
> >> > with template information in it ot help speed up compiling of code that
> >> > uses the STL.
> >>
> > I understand that not parsing template definitions also means not catching
> > syntax errors until they are instantiated, however to me that is a minor
> > drawback which can easily be fixed with a command line option...
> 
> That way lies madness.  There will only be one implementation of templates
> in the compiler.

Well I am not going to argue with you here becuase I would just make a fool
out of myself. As I have 0 experence in writting compilers.

> > Truefully I find the compile time for code that uses the STL ridiculously
> > slow and there seams to me that they has got to be a way to speed things
> > up by a factor of 1/2 or more...
> 
> Try profiling the compiler to see where it's spending all of its time.

How would I do that?  Sorry for the ignorance.

Re: Precompiled headers and General Parsing of Header File

[Cotton Seed]

Jason Merrill writes:
 >   void f (int);
 > 
 >   template <class T>
 >   void g (T)
 >   {
 >     f (1.0);
 >   }
 > 
 >   void f (double);
 > 
 >   main ()
 >   {
 >     g (24);
 >   }
 > 
 > Here, the call to f in g is bound immediately to f(int), since 1.0 does not
 > depend on T, even though at g's point of instantiation there is a better
 > match.  g++ actually doesn't get this right yet, but it's why we have to
 > parse templates immediately.

We do this by "dating" the scopes.  f(double) is not visible from
within g since the date of f(double) is older than that of the delayed
f in g.  Of course, this doesn't fix your problem of a non-reentrant
parser.

        - Cotton

Re: Precompiled headers and General Parsing of Header File

[Noel Yap]

Kevin Atkinson wrote:
> Truefully I find the compile time for code that uses the STL ridiculously slow
> and there seams to me that they has got to be a way to speed things up by a
> factor of 1/2 or more...

IIRC, older Sun compilers stored a database of precompiled (or was
pre-processed) header files in a database.  Perhaps egcs could do a
similar thing?  I guess the problem is knowing when to update the
database -- IMHO, the real problem is that templates don't fit in well
with the single-pass, compile/link model, but I guess we're stuck with
it.

Noel

Re: Precompiled headers and General Parsing of Header File

[Mumit Khan]

On Thu, 30 Jul 1998, Carlo Wood wrote:

> 
> There is something else that makes me think however...
> It seemed to me that I could accomplish the same
> by using -fno-implicit-templates and instantiating
> templates only once, in a single source file.
> (I automated the generation of the instantiations,
> and it worked with gcc-2.7.x.  It does NOT work with
> gcc-2.8.x and egcs, and I believe these to be broken).
> But, the speed up of this was VERY little. Almost nothing
> (maybe 10% faster).

Carlo,

I believe this is the second time you've mentioned that the combination of
-fno-implicit-templates with explicit instantiation is broken; could you
please elaborate what is broken with a few examples? I use it extensively
on all platforms except for ELF and PE-COFF, and so far I haven't had too
many problems.

I also don't understand what speedup you're referring to. For compile time
or runtime?

One change is that egcs-1.0.x expects return type on template function
instantiations whereas gcc-2.7.x simply ignored it (so you could simply
use void).

If you're using STL and had things working with 2.7.x, then there are of
course many changes due to the use of SGI STL. I have some old code that
had compile time switches to change between ObjectSpace STL and HP STL
and I had to rewrite the STL instantiations to make it work with egcs;
it was annnoying, but didn't take too long to convert a rather large body
of code making extensive use explicit instantiations.

Regards,
Mumit

Re: precompiled headers?

[Martin v. Loewis]

> There was a discussion in comp*gcc about precompiled headers. As to
> implement them in gcc or not and is it at all meaningful. Is that
> discussion 'inherited' by the egcs developers' community? Are there any
> plans to implement precompiled headers in egcs?

I don't think there are plans to implement precompiled headers at this
time. As to whether this is meaningful, and whether it can be done:
You probably get the same comments here as you do on comp*gcc.

Regards,
Martin

Re: precompiled headers?

[Zack Weinberg]

On 02 May 1999 12:29:56 +0200, Per Abrahamsen wrote:
>"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:
>
>> I don't think there are plans to implement precompiled headers at this
>> time. 

cccp already contains a partial implementation.  I don't think it was
ever finished or even gotten to the point of vaguely working.  It
looks to date from the same era as the interpreted-C dead end.

zw

precompiled headers?

[Alexader V. Voinov]

There was a discussion in comp*gcc about precompiled headers. As to
implement them in gcc or not and is it at all meaningful. Is that
discussion 'inherited' by the egcs developers' community? Are there any
plans to implement precompiled headers in egcs?

WBR

Alexander

Re: precompiled headers?

[Per Abrahamsen]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

> I don't think there are plans to implement precompiled headers at this
> time. 

From <URL: http://www.cygnus.com/news/corel.html >:

        Specifically, Cygnus will work with Corel to migrate the
        existing code to Linux and will support the following
        functionality in GNUPro:

        * Pre-compiled header support to provide significant
          build-time speedups

        ...

I assume this work will find its way to egcs, eventually. 

Re: precompiled headers?

[Zack Weinberg]

On 02 May 1999 12:29:56 +0200, Per Abrahamsen wrote:
>"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:
>
>> I don't think there are plans to implement precompiled headers at this
>> time. 

cccp already contains a partial implementation.  I don't think it was
ever finished or even gotten to the point of vaguely working.  It
looks to date from the same era as the interpreted-C dead end.

zw

Re: precompiled headers?

[Per Abrahamsen]

"Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> writes:

> I don't think there are plans to implement precompiled headers at this
> time. 

From <URL: http://www.cygnus.com/news/corel.html >:

        Specifically, Cygnus will work with Corel to migrate the
        existing code to Linux and will support the following
        functionality in GNUPro:

        * Pre-compiled header support to provide significant
          build-time speedups

        ...

I assume this work will find its way to egcs, eventually. 

Re: precompiled headers?

[Martin v. Loewis]

> There was a discussion in comp*gcc about precompiled headers. As to
> implement them in gcc or not and is it at all meaningful. Is that
> discussion 'inherited' by the egcs developers' community? Are there any
> plans to implement precompiled headers in egcs?

I don't think there are plans to implement precompiled headers at this
time. As to whether this is meaningful, and whether it can be done:
You probably get the same comments here as you do on comp*gcc.

Regards,
Martin

precompiled headers?

[Alexader V. Voinov]

There was a discussion in comp*gcc about precompiled headers. As to
implement them in gcc or not and is it at all meaningful. Is that
discussion 'inherited' by the egcs developers' community? Are there any
plans to implement precompiled headers in egcs?

WBR

Alexander