Compiling DynFlags is jolly slow

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Compiling DynFlags is jolly slow

Ian Lynagh-2
On Thu, Jan 31, 2013 at 12:23:02PM -0000, GHC wrote:
>
>  I can't compile `DynFlags` on my 256MB Raspberry Pi.  Could we do
>  something about having less auto-generated code in this module please?
>
> --
> Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7258#comment:13>

The ticket's really about performance problems in the compiler rather
than DynFlags in particular, so moving to the list.

Even the non-generated code in DynFlags is quite large, and ungainly to
edit. What would you think about splitting it up, perhaps moving
DumpFlag, GeneralFlag and WarningFlag into separate modules?

Ideally each module would also export a [Flag (CmdLineP DynFlags)],
which would then be ++ed together in DynFlags, but I'm not sure if
that's possible without making the modules mutually recursive. On the
other hand, perhaps there's a way to split it up which would remove the
need for (some of) the existing import loops; I'm not sure how feasible
that is OTTOMH.


Thanks
Ian



Reply | Threaded
Open this post in threaded view
|

Compiling DynFlags is jolly slow

Simon Marlow-7
On 31/01/13 18:57, Ian Lynagh wrote:

> On Thu, Jan 31, 2013 at 12:23:02PM -0000, GHC wrote:
>>
>>   I can't compile `DynFlags` on my 256MB Raspberry Pi.  Could we do
>>   something about having less auto-generated code in this module please?
>>
>> --
>> Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7258#comment:13>
>
> The ticket's really about performance problems in the compiler rather
> than DynFlags in particular, so moving to the list.
>
> Even the non-generated code in DynFlags is quite large, and ungainly to
> edit. What would you think about splitting it up, perhaps moving
> DumpFlag, GeneralFlag and WarningFlag into separate modules?
>
> Ideally each module would also export a [Flag (CmdLineP DynFlags)],
> which would then be ++ed together in DynFlags, but I'm not sure if
> that's possible without making the modules mutually recursive. On the
> other hand, perhaps there's a way to split it up which would remove the
> need for (some of) the existing import loops; I'm not sure how feasible
> that is OTTOMH.

What about just moving PlatformConstants into a separate module?

The deriving Read is the main problem - couldn't you generate a ReadP
parser instead?  Commenting out the deriving Read makes DynFlags compile
twice as fast.  It may be a GHC bug, but fixing that won't help us when
bootstrapping with older compilers.

Cheers,
        Simon



Reply | Threaded
Open this post in threaded view
|

Compiling DynFlags is jolly slow

Ian Lynagh-2
On Mon, Feb 04, 2013 at 11:50:17AM +0000, Simon Marlow wrote:
>
> What about just moving PlatformConstants into a separate module?

Done.


Thanks
Ian