#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