Hello Simon,
Sorry for the delay.
On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow
Questions:
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'?
My guess is that this won't have a significant impact on ghc -c compile times.
The advantage of squashing the .hi files for a package together is that they could share a string table, which would save a bit of space and time, but I think the time saved is small compared to the cost of deserialising and typechecking the declarations from the interface, which still has to be done. In fact it might make things worse, if the string table for the whole base package is larger than the individual tables that would be read from .hi files. I don't think mmap() will buy very much over the current scheme of just reading the file into a ByteArray.
Thank you for the answer. I'll be working on another project during the summer, but I'm still interested in making interface files load faster. The idea that I currently like the most is to make it possible to save and load objects in the "GHC heap format". That way, deserialisation could be done with a simple fread() and a fast pointer fixup pass, which would hopefully make running many 'ghc -c' processes as fast as a single 'ghc --make'. This trick is commonly employed in the games industry to speed-up load times [1]. Given that Haskell is a garbage-collected language, the implementation will be trickier than in C++ and will have to be done on the RTS level. Is this a good idea? How hard it would be to implement this optimisation? Another idea (that I like less) is to implement a "build server" mode for GHC. That way, instead of a single 'ghc --make' we could run several ghc build servers in parallel. However, Evan Laforge's efforts in this direction didn't bring the expected speedup. Perhaps it's possible to improve on his work. [1] http://www.gamasutra.com/view/feature/132376/delicious_data_baking.php?print... -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments