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) |
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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.