#5113: Huge performance regression of 7.0.2, 7.0.3 and HEAD over 7.0.1 and 6.12 (MonoLocalBinds) --------------------------------------+------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 7.0.3 Resolution: fixed | Keywords: performance, MonoLocalBinds Os: Linux | Architecture: x86 Failure: Runtime performance bug | Difficulty: Unknown Testcase: perf/should_run/T5113 | Blockedby: Blocking: | Related: --------------------------------------+------------------------------------- Changes (by simonpj): * difficulty: => Unknown Comment: This patch is the crucial one that fixes the original problem {{{ commit b5c18c91da911a7729563207c7b95f7e452cca7e Author: Simon Peyton Jones <simonpj@microsoft.com> Date: Fri Feb 8 17:29:40 2013 +0000 Fix an old and egregious specialisation bug (Trac #5113) The specialiser needs to know if a dictionay has some structure, so that it can decide whether to specialise a function. Eg (A) let d = $dfblah d1 in ....(f d).... (B) \d. ....(f d).... In (A) it's probably worth specialising f; in (B) it isn't. Previously we were relying on d's unfolding, but the specialiser does cloning as it goes, which discards the unfolding. So we were simply discarding all specialisations for functions with local dictionary bindings! This bug seems to have been there for a long time. This is what originally caused Trac #5113. Then we went through a phase where local bindings were not generalised, and that meant there was no locally overloaded f to specialise; so the performance problem appeared to be fixed. But now we are generalising local bindings again, so it re-appeared. This patch fixes the original problem. compiler/specialise/Specialise.lhs | 390 ++++++++++++++++++++---------------- 1 files changed, 214 insertions(+), 176 deletions(-) }}} -- Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5113#comment:6> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler