
#8763: forM_ [1..N] does not get fused (10 times slower than go function) -------------------------------------+------------------------------------- Reporter: nh2 | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.6.1 Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime | Unknown/Multiple performance bug | Test Case: Blocked By: | Blocking: Related Tickets: #7206 | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by sgraf): Note that's not a problem for `[x..y]` (`eftInt`), because that doesn't need to consider counting down. It's not an issue for `[x,y..]` (`edtInt`), because although it calls `efdtInt{Up,Dn}` internally, it doesn't take part in fusion at all (is that an oversight or by design?). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8763#comment:59 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler