[GHC] #15519: Minor code refactoring leads to drastic performance degradation

[GHC]

#15519: Minor code refactoring leads to drastic performance degradation
-------------------------------------+-------------------------------------
        Reporter:  danilo2           |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  highest           |            Milestone:  8.8.1
       Component:  Compiler          |              Version:  8.4.3
      Resolution:                    |             Keywords:  SpecConstr
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by simonpj):

 >  I strongly disagree with the sentence that the "fix would be to remove
 INLINE pragma"

 I didn't say that!  I said that a ''workaround'' is to remove the INLINE
 pragma :-).  I agree that it's insane that adding INLINE makes things
 worse, and I propose to change GHC so that INLINE is honoured even for
 0-ary values, and even if doing so would cause work duplication.

 I think that this alone will help you a lot, addressing 2,3,4.

 As to (5), yes, eta expansion is a particularly tricky transformation for
 GHC. In performance critical code, do it by hand.

 Re (6) you could put it another way: `SpecConstr` gives you absolutely
 stunning performance gains!  Without you'd have had less good perf, but
 reliably so, and you would not be submitting this ticket :-).  So there is
 a positive side here.

 The trouble is that it's difficult for `SpecConstr` to give ''reliably''
 good perf, and that's why this horrible SPEC business is there.  I'm sure
 it's possible to do better -- but it needs someone to really study the
 problem carefully. It's not just an easy fix.

 Re (7) SPEC is not well documented.  The best documentation is probably
 `Note [Forcing specialisation]` in `SpecConstr` itself.  It is a HORRIBLE
 hack, but we were never able to come up with anything more civilized.
 Again, it would reward some sustained attention. (I'm not addressing you
 here, rather any GHC hackers or research students looking for an
 interesting challenge.)

-- 
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/15519#comment:16>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler