Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'

[Ryan Newton]

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 <marlowsd at 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.rise at 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 at haskell.**org <Glasgow-haskell-users at haskell.org>
> http://www.haskell.org/**mailman/listinfo/glasgow-**haskell-users<http://www.haskell.org/mailman/listinfo/glasgow-haskell-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20120517/0270b111/attachment.htm>