Compiling DynFlags is jolly slow
marlowsd at gmail.com
Mon Feb 4 12:50:17 CET 2013
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.
More information about the ghc-devs