Compiling DynFlags is jolly slow

[Simon Marlow]

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