#11735: Optimize coercionKind -------------------------------------+------------------------------------- Reporter: goldfire | Owner: (none) Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 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): Wiki Page: | -------------------------------------+------------------------------------- Comment (by tdammers): Replying to [comment:60 goldfire]:
I think I see what's going on here. The "cached role" results are from commit 8ac966971ec6c30cc3681a913fb9fb1c2342f6cc. This version eagerly computes the role for an `NthCo` in `mkNthCo`. This means that every (`seq`ed) `NthCo` requires a role calculation. Perhaps sometimes, we create an `NthCo` and never ever check its role. If that's the case, then 8ac96 will be worse.
On the other hand, what if you try my commit 8a6aa5030d34592200fbe799bf38abf3701544db? (Do not be thrown off by the same first two characters of the hash! I was.) That commit supplies the role to `mkNthCo`, as it can often be deduced by the caller of `mkNthCo` without too much trouble. No redundant role computation. This one should really be a clear win.
I've done another run using just these three commits, and it shows that the last one is slightly better than the original situation for the `test_rules2` case, and about the same for the `Grammar.hs` case: {{{ --- ./cases/Grammar.hs --- 4eb140f564: 12.31 8ac966971e: 12.70 8a6aa5030d: 12.31 --- ./cases/test_rules2.hs --- 4eb140f564: 1.11 8ac966971e: 1.14 8a6aa5030d: 1.09 }}} So the `8ac...` commit makes things slightly worse, but at `8a6...` we're back at equal-or-better. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11735#comment:66 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler