[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):

 Note that this is a rather extreme test case. I’m sure for a lot of
 optimizations we can construct a case where they account for most of the
 program. If it were 20% for a real-world example, I’d fully agree. Right
 now, I’m fine with the current state of affairs.

 > For example, the bigger the block the less likely it is to be identical,
 but the more expensive it is to compare (I guess). Maybe we can cut off at
 some block size?

 I doubt it. The bigger the blocks, the more likely it is that the hash is
 different.

 >  Also why are you comparing (hash, list of successor labels) rather than
 just including the successor labels in the hash?

 Because the successor labels change (or rather the equality on them) as we
 common up blocks; the hash is calculated exactly once. I guess you are
 implicitly asking for more comments. Added it to the body of text already
 there.

 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.

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