On 03/09/2011 02:05, Evan Laforge wrote:
Another way to do this would be to have GHC --make invoke itself to
compile each module separately. Actually I think I prefer this method,
although it might be a bit slower since each individual compilation has
to read lots of interface files. The main GHC --make process would do
the final link only. A fun hack for somebody?
this would also help building large libraries on architectures with
little memory, as it seems to me that when one ghc instance is compiling
multiple modules in a row, some leaked memory/unevaluated thunks pile up
and eventually cause the compilation to abort. I suspect that building
each file on its own avoids this issue.
In my experience, reading all those .hi files is not so quick, about
1.5s for around 200 modules, on an SSD. It gets worse with a pgmF, since ghc
wants to preprocess each file, it's a minimum of 5s given 'cat' as a
preprocessor.
Part of my wanting to use make instead of --make was to avoid this
re-preprocessing delay. It's nice that it will automatically notice
which modules to recompile if a CPP define changes, but not so nice
that it has to take a lot of time to figure that out every single
compile, or for a preprocessor that doesn't have the power to change
whether the module should be recompiled or not.
Ah, but you're measuring the startup time of ghc --make, which is not
the same as the work that each individual ghc would do if ghc were
invoked separately on each module, for two reasons:
- when used in one-shot mode (i.e. without --make), ghc only reads
and processes the interface files it needs, lazilly
- the individual ghc's would not need to proprocess modules - that
would only be done once, by the master process, before starting
the subprocesses. The preprocessed source would be cached,
exactly as it is now by --make.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
