Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
the.dead.shall.rise at gmail.com
Mon Apr 2 08:37:21 CEST 2012
[Hoping it's not too late.]
During my work on parallelising 'ghc --make'  I encountered a
stumbling block: running 'ghc --make' can be often much faster than
using separate compile ('ghc -c') and link stages, which means that
any parallel build tool built on top of 'ghc -c' will be significantly
handicapped . As far as I understand, this is mainly due to the
effects of interface file caching - 'ghc --make' only needs to parse
and load them once. One potential improvement (suggested by Duncan
Coutts ) is to produce whole-package interface files and load them
in using mmap().
Would implementing this optimisation be a worthwhile/realistic GSoC project?
What are other potential ways to bring 'ghc -c' performance up to par
with 'ghc --make'?
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
More information about the Glasgow-haskell-users