#2252: Extreme performance degradation on minor code change
----------------------+-----------------------------------------------------
Reporter: simona | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: Compiler | Version: 6.8.2
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: x86_64 (amd64)
Os: Linux |
----------------------+-----------------------------------------------------
Changes (by simonpj):
* difficulty: => Unknown
Comment:
That is odd, I grant you.
However your code repeats the same computation 1000 times. That
computation is in the I/O monad, ''but it does no I/O'' (or at least only
outside the loop). Hence a clever optimiser might spot that it must give
the same result every time, and compute that result just once.
I bet that is what is happening here. The "clever optimiser" may be
somehow put off the scent by the minor change in structure of your program
-- without more info I couldn't say exactly why.
If I'm right, then it's arguably bad that a minor change could make such a
big performance difference. But repeating an identical computation 1000
times is equally arguably not something that a compiler should be robustly
optimising for.
Of course I could be on the wrong track. Try `-ddump-simpl` and attach
the output from that. You might like to look into that output for top-
level definitions that look like `lvl_*`; these are the ones floated of
loops. Also try `-fno-full-laziness` to switch off the full laziness
transformation, and see if that make Good perform the same as Bad.
Simon
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2252#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
