Hello Simon, Sorry for the delay.
On Tue, Apr 10, 2012 at 1:03 PM, Simon Marlow <marlo...@gmail.com> wrote: > >> 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=1 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
