[GHC] #10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks

[GHC]

#10397: Compiler performance regression 7.6 -> 7.8 in elimCommonBlocks
-------------------------------------+-------------------------------------
        Reporter:  TobyGoodwin       |                   Owner:
            Type:  bug               |                  Status:  merge
        Priority:  normal            |               Milestone:  7.10.2
       Component:  Compiler          |                 Version:  7.8.4
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |  performance
 Type of failure:  None/Unknown      |            Architecture:
      Blocked By:                    |  Unknown/Multiple
 Related Tickets:                    |               Test Case:  see ticket
                                     |                Blocking:
                                     |  Differential Revisions:  Phab:D892
-------------------------------------+-------------------------------------

Comment (by nomeata):

 Replying to [comment:23 nomeata]:
 > I wonder if it is faster to hash the list of labels and group them using
 a single level IntMap instead of the current trie based on nested
 IntMap.... That’s worth a try.

 no, it’s not. And profiling shows why: The time is still spent mostly in
 `eqBlockBodyWith`. With my refactoring, the number of calls to that
 function is minimal anyways, so the only way to improve the situation is
  * a better hash function (it currently does not take operators into
 account, and maybe it can also take “internal” functions into account)
  * no linear search by using a trie for blocks, similar how we do it for
 Core expressions.
  * lose precision.

 I’ll add some debug output to see how these blocks that cannot be merged
 look like.

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10397#comment:24>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler