#8763: forM_ [1..N] does not get fused (10 times slower than go function) --------------------------------------------+------------------------------ Reporter: nh2 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Runtime performance bug | Unknown/Multiple Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: --------------------------------------------+------------------------------ Comment (by nh2): People on #ghc think that it is because the {{{[1.._N]}}} gets floated out as a top-level constant expression: ---- '''nomeata:''' nh2: I’d consider that a bug '''nomeata:''' I believe the problem is that [0..512] does not depend on any local values '''nomeata:''' so it is floated out as a top-level value '''nomeata:''' and there it is not matched by any rules '''thoughtpolice:''' let floating strikes again '''thoughtpolice:''' (well, floating-out being a non-optimization, anyway.) '''Fuuzetsu:''' does this mean that if I use [0 .. 512] twice in a program in different places, it will only be computed once? '''hvr:''' Fuuzetsu: there's a chance, yes '''Fuuzetsu:''' neat '''thoughtpolice:''' well, not so neat. in cases like this you really don't want to float out some things, because it hurts later opportunities to optimize sometimes (e.g. float out a binding that otherwise would have triggered a RULE or fusion, perhaps) '''thoughtpolice:''' unfortunately floating like this is one of the harder things to 'fight against' when you don't want it, from what i've seen. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8763#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler