#11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g) -------------------------------------+------------------------------------- Reporter: slyfox | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): phab:D3001 Wiki Page: | -------------------------------------+------------------------------------- Comment (by scpmw): Right, the source note gets floated outside of the `(:)` application, at which point the inner-most `()` is covered by source notes of all `()` in the list. Thus we get a quadratic growth of source notes, and redundancy checks blow this up to `O(n^3)`. Ouch. Ironically, this would likely not happen without the syntactic sugar, as then a source note would span the whole `(a:b)` expression (instead of just `b`), which would get eliminated by the mentioned "contains" check. This is what normally gives this stability: Once a tick gets flown up, it immediately hits a tick that covers a greater span, causing it to get eliminated. So maybe changing desugaring could actually take care of this. We could also attempt to merge ticks automatically. This would make them slightly less useful, but is clearly better than blowing up the compiler. On the other hand, not sure what the criterion for merging should look like. If we go by the span alone, we run into the tricky question of how far two spans can be apart until we must assume that merging them would stop making sense. Unfortunately, I doubt it would be hard to make up examples to make any given threshold look bad. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11095#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler