#12191: 7% allocation regression in Haddock performance tests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by thomie): * related: => #10482 Comment: How about we just delete those 3 haddock performance tests? From https://mail.haskell.org/pipermail/ghc-devs/2015-July/009434.html:

...

Simon Peyton Jones wrote: Could it be creeping up because Haddock is doing more than before? Ie not just because GHC is being bad? Yes, it very much could be. Haddock is a moving target so it's not too weird that the numbers change. I want to say that the perf test should just be removed but it's still useful: if you're GHC hacking and not changing Haddock and numbers go awry then it serves its purpose.

-- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12191#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12191: 7% allocation regression in Haddock performance tests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: niteria Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): @nomeata: Thanks for running these. I think I had to disable `haddock` before `./validate` because it was broken and that's how this snuck in. I will take a look this week (but unfortunately not tomorrow). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12191#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12191: 7% allocation regression in Haddock performance tests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: niteria Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Simon Peyton Jones ): In [changeset:"70a458938c36849f78c6efc65a088289ebc4e293/ghc" 70a4589/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="70a458938c36849f78c6efc65a088289ebc4e293" Revert "Make the Ord Module independent of Unique order" This reverts commit 0497ee504cc9ac5d6babee9b98bf779b3fc50b98. Reason: See Trac #12191. I'm reverting pending Bartosz's investigation of what went wrong. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12191#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12191: 7% allocation regression in Haddock performance tests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: niteria Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by simonmar): @thomie, Note that the Haddock perf test is really a GHC perf test, because most of the work that Haddock does is loading source files and typechecking them using the GHC API. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12191#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12191: 7% allocation regression in Haddock performance tests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: niteria Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by niteria): So what's happening in `checkFamInstConsistency` is suboptimal in multiple ways: 1) The algorithm itself is quadratic. It checks every module against every other module. It appears to me that the same thing can be done in a linear way by maintaining a consistent env of family instances so far and fold adding there when possible or reporting an error. 2) `checkFamInstConsistency` in Haddock appears to be called for every module (Haddock is equivalent to `--make`, right?) which is redundant and in principle could be done at the very end once. 3) determining what pairs to compare uses `Set ModulePair`. After my change `Ord ModulePair` is linear. The size of the set is quadratic. Furthermore the `Ord ModulePair` doesn't cache its canonicalization. 4) given these there still appear to be better and worse orders for the `ModulePair`s. I don't really know why. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12191#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12191: 7% allocation regression in Haddock performance tests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: niteria Type: task | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Bartosz Nitka ): In [changeset:"123062946dfdbcfc24abd468e24e358118b8e2eb/ghc" 12306294/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="123062946dfdbcfc24abd468e24e358118b8e2eb" Make checkFamInstConsistency less expensive Doing canonicalization on every comparison turned out to be very expensive. Caching the canonicalization through the smart `modulePair` constructor gives `8%` reduction in allocations on `haddock.compiler` and `8.5%` reduction in allocations on `haddock.Cabal`. Possibly other things as well, but it's really visible in Haddock. Test Plan: ./validate Reviewers: jstolarek, simonpj, austin, simonmar, bgamari Reviewed By: simonpj, simonmar Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2350 GHC Trac Issues: #12191 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12191#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#12191: 7% allocation regression in Haddock performance tests -------------------------------------+------------------------------------- Reporter: bgamari | Owner: niteria Type: task | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #10482 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Changes (by niteria): * status: new => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/12191#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler