This is the mail archive of the
mailing list for the GCC project.
RE: reduce compilation times?
- From: "Duft Markus" <Markus dot Duft at salomon dot at>
- To: "Tom St Denis" <tstdenis at ellipticsemi dot com>, "NightStrike" <nightstrike at gmail dot com>
- Cc: "J.C. Pizarro" <jcpiza at gmail dot com>, "Galloth" <lordgalloth at gmail dot com>, <gcc-help at gcc dot gnu dot org>
- Date: Wed, 28 Nov 2007 08:32:08 +0100
- Subject: RE: reduce compilation times?
I assume, that all strategies discussed here are targeted at C. now what
about C++, how do things behave there? As far as i know C++ is much
different, and requires completely different thinking with regards to
splitting source in more files, etc.
Tom St Denis <> wrote:
> NightStrike wrote:
>> On Nov 27, 2007 11:43 AM, Tom St Denis <email@example.com>
>>> This is why you should re-factor your code as to contain only one
>>> [or as few as possible] exportable functions per unit.
>> Just so I understand (and I realize that this would not be done), but
>> let's say that I have a machine that can compile extraordinarily
>> quickly, and compile time was not a factor. Is there a difference in
>> the speed of the resulting program when everything is split into many
>> object files instead of being combined into a single main.c, or is
>> the resulting binary identical bit for bit?
> The only time it would matter (legally) is if there was inline'ing.
> And really, you should be setting that up yourself with the "inline"
> tag (or macros).
> suppose you had something like
> int myfunc(int x)
> return x * x + x * x;
> and you only called it from main like
> int main(void)
> int res;
> res = myfunc(0);
> Can the compiler special case optimize it? Well, strictly yes, the
> compiler could inline "myfunc" then reduce it. Suppose "myfunc" is
> more complicated or larger and it couldn't be inlined. If the
> compiler could determine the result at buildtime it would be legal to
> optimize it out, but if it can't it won't and it will call the
> function. So really, in all but the trivial cases [dead code, etc]
> having everything in one unit, especially when your functions aren't
> static, won't help reduce code size or speed.
> What you really should do, is profile your code, then create "static
> inline" or macro copies of heavily used (and not overly large) pieces
> of code. And even then, inlining code doesn't always help.
> Putting everything in one big file has several disadvantages though:
> - It increases build time, every time you build it [which could be
> 1000s of times]
> - It makes content control harder since you have to lock larger
> portions of the project to work on it
> - It makes editing harder as you have more to scroll/look through
> - It decreases [not always though] the ability to use smart linking,
> which can increase image size
> - It makes building on smaller machines [with less ram, slower
> processors, etc] harder
> Ideally, but this isn't a hard set rule, you want to keep each source
> file under 200-300 lines (excluding tables). It's not a sin to
> violate it here or there where it makes sense. Most of the time
> though, it's a good idea to try for it.
> In both of my OSS projects, the average file has 1 function in it, and
> is ~150-200 lines per file. The exceptions being machine generated
> code (e.g. unrolled multipliers), and lookup tables for
5. Dezember 2007
Salomon Automation am Schweizer Forum fur Logistik, Lausanne, CH
Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz