#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D632 -------------------------------------+------------------------------------- Comment (by dfeuer): Replying to [comment:1 simonpj]:

Can you offer a reproducible test case, and timing or allocation data?

I had one, and then I lost it. I wish I could give you one as a test case and for future analysis. It was something very simple, and the `mapM_` of 4.7 was consistently the same as the version in the linked differential, and both allocated less than the version currently in head. I believe it had to be an arity issue. Call arity wasn't catching it for some reason, so it needed input from the other arity analysis that it wasn't getting. Consider the current definition: {{{#!hs mapM_ f = foldr ((>>) . f) (return ()) }}} Taking apart the argument to `foldr` above gives {{{#!hs mapM_ f = foldr (\m -> (>>) (f m)) (return ()) }}} Now fuse this with `build g`: {{{#!hs mapM_ f (build g) = g (\m -> (>>) (f m)) (return ()) }}} Without knowing what the monad is, `mapM_` doesn't know that `(>>)` has arity 2, and relies on Call Arity analysis of `g`, which I imagine wasn't working in whatever example I was dealing with. What I propose below forces the arity up to 2, and is also significantly easier to read. {{{#!hs {-# INLINE mapM_ #-} mapM_ f = foldr (\m n -> f m >> n) (return ()) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10034#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D632 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"7cf87fc6928f0252d9f61719e2344e6c69237079/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="7cf87fc6928f0252d9f61719e2344e6c69237079" Eta-expand argument to foldr in mapM_ for [] Summary: This improves performance, at least sometimes--the previous implementation can be worse than the version in base 4.7. I have not had the time to run benchmarks and such, but `mapM` already does this. Also, inline `mapM_`, like `mapM`. Reviewers: hvr, nomeata, ekmett, austin Reviewed By: ekmett, austin Subscribers: thomie Projects: #ghc Differential Revision: https://phabricator.haskell.org/D632 GHC Trac Issues: #10034 }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10034#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: ekmett Type: bug | Status: new Priority: highest | Milestone: 7.10.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D632 -------------------------------------+------------------------------------- Comment (by Austin Seipp ): In [changeset:"91d9530525803403c3c012901115d54ff4fc3b5e/ghc"]: {{{ #!CommitTicketReference repository="ghc" revision="91d9530525803403c3c012901115d54ff4fc3b5e" Revert "Eta-expand argument to foldr in mapM_ for []" This change lacked justification (or a test!) for its improvements, and I merged it on a sweep of Phabricator without fixing this. Trac #10034. This reverts commit 7cf87fc6928f0252d9f61719e2344e6c69237079. }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10034#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: new Priority: normal | Milestone: 7.12.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D632 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: ekmett => bgamari -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10034#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler

#10034: Regression in mapM_ performance -------------------------------------+------------------------------------- Reporter: dfeuer | Owner: bgamari Type: bug | Status: closed Priority: normal | Milestone: 8.0.1 Component: Core Libraries | Version: 7.10.1-rc2 Resolution: invalid | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D632 Wiki Page: | -------------------------------------+------------------------------------- Changes (by bgamari): * cc: ekmett (added) * status: new => closed * resolution: => invalid Comment: Closing as we don't have an example demonstrating the issue. David, feel free to reopen if you do come upon a testcase. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10034#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler