RE: reduce compilation times?

["Duft Markus" <Markus dot Duft at salomon dot at>]

Hi!

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.

Cheers, Markus

Tom St Denis <> wrote:
> NightStrike wrote:
>> On Nov 27, 2007 11:43 AM, Tom St Denis <tstdenis@ellipticsemi.com>
>> wrote: 
>> 
>>> 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
> hashes/ciphers. 
> 
> Tom


-- 
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