#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