Re: C++

[Sam Mason]

On Mon, Nov 09, 2009 at 09:19:47AM -0800, Jonathan S. Shapiro wrote:
> On Mon, Nov 9, 2009 at 8:32 AM, Sam Mason <address@hidden> wrote:
> > Fun!  Link times would be even more of a problem then, Google's linker
> > "gold" was about helping with this a bit (five times?) but if you move
> > optimization into the linker this is going to get much slower again.
> 
> Not really. Optimization takes what it takes. The question is whether
> you do it badly, one file at a time, or globally, one binary at a
> time.

I've not tried this, but it looks as though larger projects are taking
10 minutes for even relatively minor rebuilds:

  
http://alex.dojotoolkit.org/2009/08/note-to-a-future-self-faster-chromium-builds/

> What gets longer if certain optimizations are turned on is the
> compile/edit/debug cycle.

Keeping as much away from the link step looks like a good idea in
the above situations.  This is probably also a somewhat extreme
example though, I know it's not much a problem for me and inter-file
optimizations would help to tidy code up.

> But what's interesting is that there is a middle position where most
> of the heavy lifting is done by the front end, and the optimizations
> performed in the linker are (from a time perspective) relatively
> modest.

Yup, I agree it'd be interesting to see.

> So from a developer perspective this may be more of a "tuning knob"
> problem than anything else.

I'd still be worried about optimizations seeping across ABI's and
causing things to break down the line.  Some control seems necessary,
the fact that this is done in the currently done by a hard dividing line
between compiler and linker at the moment doesn't seem optimal.

-- 
  Sam  http://samason.me.uk/