[GHC] #10788: performance regression involving minimum

[GHC]

#10788: performance regression involving minimum
-------------------------------------+-------------------------------------
        Reporter:  rwbarton          |                   Owner:  ekmett
            Type:  bug               |                  Status:  new
        Priority:  normal            |               Milestone:
       Component:  Core Libraries    |                 Version:  7.10.1
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  Runtime           |  Unknown/Multiple
  performance bug                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:                    |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by nomeata):

 >  In this particular case, I am quite happy with the
 INLINEABLE/SPECIALIZE solution, and will submit a DR soon.

 Spoke too soon. Looking at the core of `List`, the `maximum` for `Int` is
 great (worker with a strict unboxed `Int`), but for `Integer`, the
 strictness analyzer is failing me, and I get this loop:
 {{{#!hs
 Rec {
 -- RHS size: {terms: 12, types: 8, coercions: 0}
 maximum_go [Occ=LoopBreaker] :: [Integer] -> Integer -> Integer
 [GblId, Arity=2, Caf=NoCafRefs, Str=DmdType <S,1*U><S,U>]
 maximum_go =
   \ (ds_a2d4 :: [Integer]) (eta_B1 :: Integer) ->
     case ds_a2d4 of _ [Occ=Dead] {
       [] -> eta_B1;
       : y_a2d9 ys_a2da ->
         maximum_go
           ys_a2da
           (integer-gmp-1.0.0.0:GHC.Integer.Type.$fOrdInteger_$cmax
              eta_B1 y_a2d9)
     }
 end Rec }
 }}}
 So it sees that `go` is strict in its second argument. Why is it then not
 strictly evaluated before the recursive call, avoiding this obvious space
 leak?

 Note that `max` is not inlined (as it is for Int), but the strictness data
 is there, so that should not make a difference.

 Anyways, I guess this discussion is derailing for this particular ticket.
 I’ll look into a combination of rewriting with `RULES` to `strictMinimum`
 to avoid relying on the strictness analyzer to produce good code.

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