Hi, did you try to compile it with a profiled GHC and look at the report? I would not be surprised if it would point to some obvious sub-optimal algorithms in GHC.
Greetings, Joachim Am Sonntag, den 04.12.2016, 20:04 +0000 schrieb David Turner: > Nod nod. > > amazonka-ec2 has a particularly painful module containing just a > couple of hundred type definitions and associated instances and > stuff. None of the types is enormous. There's an issue open on > GitHub[1] where I've guessed at some possible better ways of > splitting the types up to make GHC's life easier, but it'd be great > if it didn't need any such shenanigans. It's a bit of a pathological > case: auto-generated 15kLoC and lots of deriving, but I still feel it > should be possible to compile with less than 2.8GB RSS. > > [1] https://github.com/brendanhay/amazonka/issues/304 > > Cheers, > > David > > On 4 Dec 2016 19:51, "Alan & Kim Zimmerman" <alan.z...@gmail.com> > wrote: > I agree. > > I find compilation time on things with large data structures, such as > working with the GHC AST via the GHC API get pretty slow. > > To the point where I have had to explicitly disable optimisation on > HaRe, otherwise the build takes too long. > > Alan > > > On Sun, Dec 4, 2016 at 9:47 PM, Michal Terepeta <michal.terepeta@gmai > l.com> wrote: > > Hi everyone, > > > > I've been running nofib a few times recently to see the effect of > > some changes > > on compile time (not the runtime of the compiled program). And I've > > started > > wondering how representative nofib is when it comes to measuring > > compile time > > and compiler allocations? It seems that most of the nofib programs > > compile > > really quickly... > > > > Is there some collections of modules/libraries/applications that > > were put > > together with the purpose of benchmarking GHC itself and I just > > haven't > > seen/found it? > > > > If not, maybe we should create something? IMHO it sounds reasonable > > to have > > separate benchmarks for: > > - Performance of GHC itself. > > - Performance of the code generated by GHC. > > > > Thanks, > > Michal > > > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs@haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Joachim “nomeata” Breitner m...@joachim-breitner.de • https://www.joachim-breitner.de/ XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F Debian Developer: nome...@debian.org
signature.asc
Description: This is a digitally signed message part
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs