#2762: Excessive heap usage
---------------------------------+------------------------------------------
Reporter: igloo | Owner:
Type: bug | Status: new
Priority: normal | Milestone: 6.10.2
Component: Compiler | Version: 6.11
Severity: normal | Resolution:
Keywords: | Difficulty: Unknown
Testcase: | Os: Unknown/Multiple
Architecture: Unknown/Multiple |
---------------------------------+------------------------------------------
Comment (by batterseapower):
Well, I've had a look at the arity analysis idea. I'll attached a
preliminary version of the analysis. It does indeed fix some "bad"
arities, including the one in this example, but it's reasonably costly
compile-time wise and doesn't have a non-neglible effect on allocations or
runtime in Nofib, with two exceptions:
* Bspt allocates a lot more, because the call to concat in
Stdlib.seQuence is saturated by the eta-expansion step. This causes the
simplifier to inline concat at that use site (even though the arguments
are boring, since concat is a thin wrapper around a function poly_go).
This in turn leads to RULES not spotting any instances of concat during
the compilation of the Init and BSPT modules, so foldr/build fusion just
fails to happen. (NB: you need to add the missing phase activation [~1] to
the concat RULE in GHC.List to see this effect)
* Atoms runtime apparently increases a lot, though there is no apparent
difference in the STG generated in the two versions (also attached). I
can't work out why this is.
Even if we fix these problems is it really worth introducing this
analysis, given that it's effects are so small?
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/2762#comment:3>
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
