incremental linking?

[Simon Marlow]

> > > More fun with Haskell-in-the-large: linking time has become the
> > > main bottleneck in our development cycle. The standard solution
> > > would be to use an incremental linker, but it seems that gnu does
> > > not yet support this:-|
> >=20
> > Hmm, I've never heard of linking being a bottleneck.  Even=20
> GHC itself
> > links in about 3-4 seconds here.  One common problem is=20
> that linking on
> > a network filesystem takes a *lot* longer than linking=20
> objects from a
> > local disk.  It's always a good idea to keep the build tree=20
> on the local
> > disk, even if the sources are NFS-mounted.
>=20
> I also have this problem, and while being on a local disk=20
> rather than NFS
> helps, it doesn't help all that much.  For large projects, I=20
> usually have
> time to get a cup of coffee while linking (admittedly only four doors
> away, but...).  When on NFS, I have time to go to the local=20
> coffeehouse...

Ok, it looks like we need to investigate this.  NFS isn't the problem in
itself: I realised that our GHC installation is NFS-mounted on the
machine I tried the experiment on, and it makes very little difference
(although Linux's NFS implementation is a bit fast & loose when it comes
to caching, I seem to recall).

Those who experience long link times (longer than a few seconds), please
reply with your

  - platform / OS version
  - versions of relevent things (GHC, GCC, binutils).
  - time to link 'main =3D print "hello"'.

Does starting up GHCi take a long time?

Would someone like to strace (or truss, or ktrace or whatever) the ld
process and see what it is doing for all that time.  Is it CPU or I/O
bound?

Cheers,
	Simon