[GHC] #12817: Degraded performance with constraint synonyms

8 Nov 2016

      #12817: Degraded performance with constraint synonyms
-------------------------------------+-------------------------------------
           Reporter:  crockeea       |             Owner:
               Type:  bug            |            Status:  new
           Priority:  normal         |         Milestone:
          Component:  Compiler       |           Version:  8.0.1
           Keywords:                 |  Operating System:  Unknown/Multiple
       Architecture:                 |   Type of failure:  Runtime
  Unknown/Multiple                   |  performance bug
          Test Case:                 |        Blocked By:
           Blocking:                 |   Related Tickets:
Differential Rev(s):                 |         Wiki Page:
-------------------------------------+-------------------------------------
 The attached bug demonstrates how using constraint synonyms can negatively
 impact performance.

 I have two functions which are identical, except that one uses a
 constraint synonym:

 {{{
 type CElt r = (Num r, Eq r)

 fooSlow :: (CElt r) => Bar r -> Bar r
 {-# INLINABLE fooSlow #-}
 fooSlow (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar .
 eitherFoo) u
 fooSlow (C2 c) = C2 $ fooSlow c

 fooFast :: (Num r, Eq r) => Bar r -> Bar r
 {-# INLINABLE fooFast #-}
 fooFast (C1 u) = either (fromEitherBar . eitherFoo) (fromEitherBar .
 eitherFoo) u
 fooFast (C2 c) = C2 $ fooFast c
 }}}

 Using criterion, `fooSlow` is about 3x slower than `fooFast`. Main.hs
 needs `criterion` and `deepseq`, but the problem should be evident just
 from inspecting the core of Bar.hs, which only relies on `base`. Code was
 compiled with GHC-8.0.1 with `-O2`.

--
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12817
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler