[GHC] #8814: 7.8 optimizes attoparsec improperly
GHC
ghc-devs at haskell.org
Thu Mar 6 21:49:33 UTC 2014
#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
More information about the ghc-tickets
mailing list