#8814: 7.8 optimizes attoparsec improperly --------------------------------------------+------------------------------ Reporter: joelteon | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.1-rc1 Resolution: | Keywords: Operating System: MacOS X | Architecture: x86_64 Type of failure: Runtime performance bug | (amd64) Test Case: | Difficulty: Unknown Blocking: | Blocked By: | Related Tickets: #8763 --------------------------------------------+------------------------------ Comment (by simonpj): What would be really helpful would be if you, or someone else, could diagnose exactly why the slow-down is happening. If you compile with `-ticky` you can very quickly zero in on the code that is taking more time, and compare one with the other. It would be remarkable if fusion was really responsible for such an enormous change in time, but perhpas it is. Maybe it would be worth commenting out RULES one at a time, to see which (if any) is responsible, and to reduce accidental differences between the two. Maybe the test case can be boiled down quite a lot further. You can switch off ALL rule rewrites with `-fno-enable-rewrite-rules`. Switching off full laziness might also be a good thing to try `-fno-full- laziness`. Reducing the inlining threshold (which doesn't affect INLINE pragmas) would mean less looking at inlined code. `-funfolding-use-threshold=N` (default is 60) It's a bit fiddly and time consuming, which is why I was appealing for help. I'll gladly explain anything you (or whoever) wants to know about the GHC end of things. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/8814#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler