Mikhail's original question was about loading interface files for entire packages with mmap.
As a wild thought experiment, if GHC had a saved-heaps capability, I believe that would avoid the Unique issues with mmap'ing individual data structures that Simon mentioned. How about if each whole-package interface were then a GHC saved heap that, when booted, would become an "interface" server that would communicate with, and be shared by, other GHC build server processes. -Ryan On Fri, Apr 27, 2012 at 4:57 AM, Simon Marlow <marlo...@gmail.com> wrote: > On 26/04/2012 23:32, Johan Tibell wrote: > >> On Thu, Apr 26, 2012 at 2:34 PM, Mikhail Glushenkov >> <the.dead.shall.r...@gmail.com**> wrote: >> >>> Thanks. I'll look into how to optimise .hi loading by more traditional >>> means, then. >>> >> >> Lennart is working on speeding up the binary package (which I believe >> is used to decode the .hi files.) His work might benefit this effort. >> > > We're still using our own Binary library in GHC. There's no good reason > for that, unless using the binary package would be a performance > regression. (we don't know whether that's the case or not, with the current > binary). > > Cheers, > Simon > > > > > ______________________________**_________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users@haskell.**org <Glasgow-haskell-users@haskell.org> > http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users<http://www.haskell.org/mailman/listinfo/glasgow-haskell-users> >
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
