> I bet you are right about interface files; GHC reads a lot of them.
> Storing them in binary format rather than ASCII might also be a win.
Personally, I am happy to pay for readability of .hi files
with some performance.
> > I think there is a better way, namely to allow interface
> > files to be stored
> > in archives rather than in directories.
>
> An archive is just a file system within a file. It's hardly a
> "better way" to duplicate a file system, when the file system
> darn well ought to perform just as well. But you may be right
> that it would work well in practice.
>
> I don't have experience of this stuff, and it's hard to predict
> the performance improvement. So it's hard to make it important
> enough to get done. Any volunteers out there?
In my experience, it pays off to store as many as possible
of the intermediate files (and even the linked binary during
development) on a local disk (e.g., on /tmp). This is
*much* faster than going via NFS.
Manuel
PS: I think, the extensive use of NFS (and probably most
other shared file systems) is a bad idea in the first
place; it is slow and a constant source of trouble. I
worked on an NFS-based system (SunOS/Solaris) for five
years and learned to hate it. Now, I have a Linux
machine with all important stuff and my home directory
on the local disk and I would never ever go back to NFS.
(Maybe a system with extensive caching and the ability
to work offline, like CODA, can provide the benfits of
NFS without the problems.)
