#7450: Regression in optimisation time of functions with many patterns (6.12 to
Reporter:  iustin                        |          Owner:                  
    Type:  bug                           |         Status:  new             
Priority:  normal                        |      Component:  Compiler        
 Version:  7.6.1                         |       Keywords:                  
      Os:  Unknown/Multiple              |   Architecture:  Unknown/Multiple
 Failure:  Compile-time performance bug  |      Blockedby:                  
Blocking:                                |        Related:                  
 In our project, we build (via TH) some not-trivial data structures,
 including custom serialisation. After growing the number of constructors
 significantly, compiling same code with ghc 7.4/7.6 is about 10 times
 slower than with ghc 6.12.

 Narrowing this down on a simpler test case, it turns out that TH is not
 the cause, just the optimisation of the generated code.

 The attached Generator.hs file generates a simple data structure (our
 project is using a much smaller number of constructors, but with more
 complex data types, and the result is the same):

 data F
   = F1 {fldF1 :: Int} |
     F2 {fldF2 :: Int} |
     F3 {fldF3 :: Int} |
     F4 {fldF4 :: Int} |
     F5 {fldF5 :: Int} |
   … deriving (Eq, Show, Read)

 prettyF :: F -> String
 prettyF (F1 v) = show v
 prettyF (F2 v) = show v

 The main.hs file just calls this splice and then does a trivial use of

 Compiling this with a variable number of constructors, with -O:


 As you can see, 6.12 looks liniar in the number of constructors, whereas
 7.6 is not anymore (at least above 100 constructors).

 Compiling without -O makes things sane again:

 After some more investigation, it turns out that just our function
 function (prettyF) with no automatic instances is cheap,
 compiling/deriving Eq/Show is also cheap, but Read is very expensive (all
 numbers with ghc 7.6):

 ||Constructors||No instances||Eq||Show||Read||

 So I believe this is about optimisation of complex functions with many
 patterns/case statements. 6.12 seems nicely liniar, whereas 7.4/7.6
 exhibit a much worse behaviour.

 This might be a known issue, or even a non-issue ("Don't use Read for
 complex types"), but I thought it's better to report it. I don't have the
 skills to look at the core result, and see if it's different or not
 between 6.12/7.6, sorry.

Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7450>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

Glasgow-haskell-bugs mailing list

Reply via email to