On Wed, Feb 17, 2016 at 4:38 AM, Ben Gamari <b...@smart-cactus.org> wrote: > Multiple modules aren't a problem. It is dependencies on Hackage > packages that complicate matters.
I guess the problem is when ghc breaks a bunch of hackage packages, you can't build with it anymore until those packages are updated, which won't happen until after the release? >From a certain point of view, this could be motivation to either break fewer things, or to patch breaking dependents as soon as the breaking patch goes into ghc. Which doesn't sound so bad in theory. Of course someone would need to spend time doing boring maintenance, but it seems that will be required regardless. And ultimately someone has to do it eventually. Of course, said person's boring time might be better spent directly addressing known performance problems. My impression from the reddit thread is that three things are going on: 1 - cabal has quite a bit of startup overhead 2 - ghc takes a long time on certain inputs, e.g. long list literals. There are probably already tickets for these. 3 - and of course, ghc can be just generally slow, in the million tiny cuts sense. I personally haven't run into these (though I don't doubt those who have), so don't get too discouraged! _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
