#12724: Be lazier about reducing type-function applications -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Description changed by simonpj: @@ -30,1 +30,3 @@ - and + + Relevant performance tests are `T3064` and `T5030` in `compiler/perf`. + Doubtless many others too. New description: Consider this: {{{ f :: F 20 -> F 20 f x = x }}} That ought to typecheck in a trice, right? But if `F` is a type function, GHC currently (8.0) eagerly reduces `F 20` to normal form. Let's say `F 20` unltimately reduces to `Int`, after a long time. Then we get {{{ f = \x . (x |> g1) |> g2 where g1 :: F 20 ~ Int g2 :: Int ~ F 20 }}} Here both `g1` and `g2` are big coercions. So we waste time reducing `F 20` ''and'' we generate giant coercions by doing so. Maybe the optimiser gets rid of them again; more probably not. But it's clearly stupid. This is one reason that the program in #5030 typechecks so slowly. We have {{{ cnst :: Integer -> Either (Immediate DummyCPU) (RegVar DummyCPU) cnst x = Left (Const x) }}} and there is absolutely no need to reduce either argument of the `Either` to normal form. Richard and I have ideas about how to fix this, but I'm recording it in a ticket. Relevant performance tests are `T3064` and `T5030` in `compiler/perf`. Doubtless many others too. -- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12724#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler