Re: speeding up compile times in C++

thutt@clark.net (Taylor Hutt)
Sat, 4 Feb 1995 02:01:25 GMT

          From comp.compilers

Related articles
speeding up compile times in C++ amichail@cs.toronto.edu (1995-01-26)
Re: speeding up compile times in C++ thutt@clark.net (1995-01-26)
Re: speeding up compile times in C++ glwinter@infi.net (1995-01-29)
Re: speeding up compile times in C++ shankar@sgi.com (1995-02-02)
Re: speeding up compile times in C++ glasss@ncp.gpt.co.uk (Steve Glass) (1995-02-03)
Re: speeding up compile times in C++ thutt@clark.net (1995-02-04)
Re: speeding up compile times in C++ rfg@rahul.net (Ronald F. Guilmette) (1995-02-04)
Re: speeding up compile times in C++ imp@boulder.openware.com (1995-02-06)
Re: speeding up compile times in C++ green@vizbiz.com (Anthony T. Green) (1995-02-06)
Re: speeding up compile times in C++ shankar@sgi.com (1995-02-08)
Re: speeding up compile times in C++ tmb@netcom.com (1995-02-12)
| List of all articles for this month |
Newsgroups: comp.compilers
From: thutt@clark.net (Taylor Hutt)
Keywords: C++, performance
Organization: Compilers Central
References: 95-02-012 95-02-050
Date: Sat, 4 Feb 1995 02:01:25 GMT

amichail@cs.toronto.edu (Amir Michail) says:
>Would this idea work? Would it improve compilation times?


Guy L. Winterbotham <glwinter@infi.net> writes:
> For a commercial slant on this idea look at Borland C++ which makes use
> of precompiled headers. As long as you can keep the .h files needed
> by your project to a known set it makes a hugh difference to compile
> time.


One important note about precompiled headers and an observation:


      Precompiled headers do not detect a memory model change. (I cannot
      speak absolutely for sure on newest versions). The drawback to this is
      that a model change without recreating the precompiled header files will
      have very adverse affects on the offsets of items in a strucutre.
      Strange errors will occur.


      A friend of mine was a precompiled header nut, until he did a test and
      found no significant difference in the compile time. Given the fact that
      the precompiled headers are absolutely huge (large, gargantuan,
      leviathan-like, on the order of megabytes in many cases), he stopped using
      them.


      As a point of reference, the symbol files stored for OP2 are usually much
      less than 5K.


Taylor Hutt <thutt@clark.net> writes:
>> Why is it that the concept of a symbol file is so hard for C++ programmers
> to understand? This problem has been solved for quite a long time with
> languages using a real module structure yet, despite this fact, C++
> programmers and writers continually propose new solutions ranging from
> wrapping anonymous structure pointers (read: opaque types) in the main
> header file (so the implementation can be changed at will) to the idea
> proposed here.




[description of an ingenious, if not strange, solution deleted]


Steve Glass <glasss@ncp.gpt.co.uk> wrote:
>Hopefully, someone out there in cfront land will take note of Taylor's
>comments because us C++ users *need* a proper solution and not yet another
>bodge ;-)


Whoa, credit where credit is due -- I just reported about someone else's
work! Regis Crelier did the thesis work at ETH, and it is a damn fine
job. The system has been implemented on a few of the Oberon systems which
ETH freely distributes -- for information on which systems, you can ask
oberon@inf.ethz.ch.


If you want to read the thesis: neptune.inf.ethz.ch:/docs/thesis/th10650.ps.Z


Taylor Hutt
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.