#2670: Performance regression
------------------------------+---------------------------------------------
Reporter: simonmar | Owner: simonpj
Type: bug | Status: new
Priority: normal | Milestone: 6.10.2
Component: Compiler | Version: 6.8.3
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Architecture: Unknown/Multiple
Os: Unknown/Multiple |
------------------------------+---------------------------------------------
Comment (by simonpj):
Diagnosis first:
* Record selector applications are always considered cheap (see
`exprIsCheap`) hence duplication of `next`.
* It's not clear why CSE doesn't eliminate the nested case.
{{{
case (next x) of r { .... (case (next x) or r' { ... } .... }
}}}
* Why isn't `next` inlined? (In the UNPACK case it actually constructs a
pair, so inlining it would eliminate that allocation. Reason: there's an
error branch `(error "Cant select next from Nil")`, which has a big static
code size. This is silly: the error branch should be floated out, and is
in the optimised code for the selector. But record selectors have a
built-in unfolding so we don't get the benefit.
* Even if we do inline it, all those duplicated error applications are a
waste of space.
* Perhaps the result-discount thing in `CoreUnfold` should not be
discombobulated by the error branch?
* We tried writing the record selectors as ordinary functions, and that
fixed the problem. More precisely, 6.10 then allocated less heap (by
about 10% or so), but strangely was a bit slower in real time. We don't
know why.
Conclusion: record selectors should probably become ordinary functions.
But watch out for consequences for dictionary record selectors.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2670#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
