Related articles |
---|
[4 earlier articles] |
Re: Fast code vs. fast compile jlilley@empathy.com (John Lilley) (1997-01-22) |
Re: Fast code vs. fast compile mwolfe@dat.cse.ogi.edu (1997-01-22) |
Re: Fast code vs. fast compile mikey@ontek.com (1997-01-22) |
Re: Fast code vs. fast compile conway@cs.mu.oz.au (1997-01-22) |
Re: Fast code vs. fast compile darius@phidani.be (Darius Blasband) (1997-01-25) |
Re: Fast code vs. fast compile wws@renaissance.cray.com (Walter Spector) (1997-01-25) |
Re: Fast code vs. fast compile kanze@gabi-soft.fr (1997-02-16) |
From: | kanze@gabi-soft.fr (J. Kanze) |
Newsgroups: | comp.compilers |
Date: | 16 Feb 1997 22:31:26 -0500 |
Organization: | GABI Software, Sarl. |
References: | 97-01-122 97-01-173 |
Keywords: | linker, performance |
mikey@ontek.com (Mike Lee) writes:
> * An often neglected contributor is linker effeciency. We were
> seeing 1/2 hour link times before we gave up and switched to shared
> libraries, even though we didn't really need them otherwise.)
I can second that. On my last project, we used two solutions to
improve build time:
1. A general tool would search out machines on which no one was logged
in on, and used these to run the compiles in parallel. Since the
builds were run overnight, we often had 20 or more machines running in
parallel.
2. We made a point of doing the links on the server which hosted the
libraries. This could easily speed up link time by a factor of three.
--
James Kanze +33 (0)1 39 55 85 62 email: kanze@gabi-soft.fr
GABI Software, Sarl., 22 rue Jacques-Lemercier, 78000 Versailles, France
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.