#15519: Minor code refactoring leads to drastic performance degradation -------------------------------------+------------------------------------- Reporter: danilo2 | Owner: (none) Type: bug | Status: new Priority: highest | Milestone: 8.8.1 Component: Compiler | Version: 8.4.3 Resolution: | Keywords: SpecConstr 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 strongly disagree with the sentence that the "fix would be to remove INLINE pragma"
I didn't say that! I said that a ''workaround'' is to remove the INLINE pragma :-). I agree that it's insane that adding INLINE makes things worse, and I propose to change GHC so that INLINE is honoured even for 0-ary values, and even if doing so would cause work duplication. I think that this alone will help you a lot, addressing 2,3,4. As to (5), yes, eta expansion is a particularly tricky transformation for GHC. In performance critical code, do it by hand. Re (6) you could put it another way: `SpecConstr` gives you absolutely stunning performance gains! Without you'd have had less good perf, but reliably so, and you would not be submitting this ticket :-). So there is a positive side here. The trouble is that it's difficult for `SpecConstr` to give ''reliably'' good perf, and that's why this horrible SPEC business is there. I'm sure it's possible to do better -- but it needs someone to really study the problem carefully. It's not just an easy fix. Re (7) SPEC is not well documented. The best documentation is probably `Note [Forcing specialisation]` in `SpecConstr` itself. It is a HORRIBLE hack, but we were never able to come up with anything more civilized. Again, it would reward some sustained attention. (I'm not addressing you here, rather any GHC hackers or research students looking for an interesting challenge.) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15519#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler