#7258: Compiling DynFlags is jolly slow -------------------------------------+------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.1 Resolution: | Keywords: deriving-perf Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonpj):
read, read-appl and show "explode" while all the other examples, including getline-appl and getline, behave properly.
Very good! {{{ sink CmmPipeline compiler/cmm/CmmPipeline.hs:(104,13)-(105,59) 77.8 23.6 SimplTopBinds SimplCore compiler/simplCore/SimplCore.hs:761:39-74 9.6 30.0 FloatOutwards SimplCore compiler/simplCore/SimplCore.hs:471:40-66 3.0 10.4 }}} What does `-dshow-passes` show about the program size? I.e. are we getting very large Core? So `sink` in C-- seems very slow. Nearly 4 bytes in 5 of all allocation is in tis pass alone. Is this a non-linear algorithmic effect. e.g if you double the size of the input, does the `sink` time go up non-linearly while `simplTopBinds` goes up linearly? That's my guess. (Related question: does `sink` show up a a big item when compiling "normal" programs?) Guessing: the "shape" of the C-- code makes `sink` behave very badly. Can you characterise what that shape is, and where the algorithmic badness comes from? This is good... fixing these performance bumps will likely help ALL programs, even ones that don't hit the really bad spots. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/7258#comment:57 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler