[GHC] #11095: -O0 -g slows GHC down on list literals (compared to -O0 without -g)

[GHC]

#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