Re: Better perf for haddock.base, haddock.Cabal (f4aa998)

Hi, Am Donnerstag, den 16.02.2017, 17:46 +0000 schrieb git@git.haskell.org:

commit f4aa9984790332a908e8b1321d00a839fb42c3ea Author: Simon Peyton Jones Date:   Thu Feb 16 17:44:58 2017 +0000

    Better perf for haddock.base, haddock.Cabal          I think this is due to       commit 6bab649bde653f13c15eba30d5007bef4a9a9d3a       Author: Simon Peyton Jones       Date:   Thu Feb 16 09:42:32 2017 +0000                Improve checking of joins in Core Lint          Improvement is around 5%.

no, https://perf.haskell.org/ghc/#revision/fc9d152b058f21ab03986ea722d0c94688b99... clearly points to this commit: commit fc9d152b058f21ab03986ea722d0c94688b9969f Author: Simon Peyton Jones < simonpj@microsoft.com > Date:   Thu Feb 16 09:41:55 2017 +0000     Comments and tiny refactor only Which is not just a refactoring. If you look at the diff, e.g. at https://phabricator.haskell.org/rGHCfc9d152b058f21ab03986ea722d0c94688b9969f you will see that after your change, the “one shot arguments according to the environment” are no longer counted towards n_val_args in fun_uds and is_exp. And it seems they should not! Is that something you understand and can explain in a note? I guess https://phabricator.haskell.org/D3089 was merged a bit prematurely in that respect.¹ Greetings, Joachim ¹ There is a workflow problem with Phab’s DR: * A creates a new DR. * B requests changes. DR now in state “revision needed” * C requests changes. DR still in state “revision needed” * A makes changes. DR now in state “needs review” * C looks at the changes and finds his concern addressed and accepts the revision. DR now in state “accepted”. * G comes along, sees a DR in state “accepted” and lands it. Problem: B did not have the chance to check the new revision. -- Joachim “nomeata” Breitner   mail@joachim-breitner.de • https://www.joachim-breitner.de/   XMPP: nomeata@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F   Debian Developer: nomeata@debian.org