Wed, 27 Nov 2002 15:55:54 -0000
> > > 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:-|
> > 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.
> 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
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