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 GHC itself links in about 3-4 seconds here. One common problem is that linking on a network filesystem takes a *lot* longer than linking objects from a local disk. It's always a good idea to keep the build tree on the local disk, even if the sources are NFS-mounted.
I also have this problem, and while being on a local disk rather than NFS helps, it doesn't help all that much. For large projects, I 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 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 = 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