[GHC] #14035: Weird performance results.
GHC
ghc-devs at haskell.org
Fri Jul 28 16:46:58 UTC 2017
#14035: Weird performance results.
-------------------------------------+-------------------------------------
Reporter: danilo2 | Owner: (none)
Type: bug | Status: new
Priority: high | Milestone:
Component: Compiler | Version: 8.0.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by simonpj):
I have made some progress.
(1), I discovered that `-XStrict` was generating some stunningly bad
desugarings for very ordinary function bindings. I have a fix in the
works. This seems to be responsible for almost all the performance loss.
(2), look at your code
{{{
FailParser ma >>= f = FailParser $ do
T b a <- ma
T b' a' <- fromFailParser $ f a
return $ T (b ||| b') a'
}}}
If `b` turns out to be `XFalse`, this amounts to
{{{
FailParser ma >>= f = FailParser $ do
T b a <- ma
T b' a' <- fromFailParser $ f a
return $ T b' a'
}}}
and GHC can re-use the (T b' a') that `fromFailParser` returned. Moreover
in the critical inner loop `b` is indeed `XFalse`:
{{{
parserLoop = parserStep >> parserLoop
}}}
because `return` returns `XFalse`.
But if you change the `(>==)` to
{{{
return $ T b a'
}}}
now GHC can't re-use anthing, and so allocate a fresh `T` every time round
the loop. So an apparently simpler program is actually more complicated!
But (2) is not a massive effect. The big thing is the desugaring. Stay
tuned.
Meanwhile, try without `-XStrict`.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/14035#comment:6>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list