#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 danilo2): @simonpj, @sgraf, first of all, thank you very much for your time, taking look at this issue and investigating it so deeply. Thanks to it I have hope we will fix it! 1. First of all I'm simply amazed by the amount of workarounds here. I know I was writing this before in other tickets, but I care a lot about predictive performance in GHC. All the described things show me that its worse than I thought, see the following points. 2. In order to write high performance code we need invariants. Rules that we can follow and we can trust that they allow us get **exactly** the behavior we want. One of the most important invariants to me (probably the most important one) was always that if I use the INLINE pragma, the code will be inlined if the call is saturated and it will have exactly the same behavior if I just copy paste it there. I always understood that the INLINE pragma is exactly for this - to very precisely guide GHC how to optimize the code. Learning that GHC does not really inline all explicitly marked saturated calls and sometimes it gets better specialization when removing the INLINE pragma is just insane. it breaks the most primitive invariant that we can rely on and without it we cannot predict just anything about the performance of code we write. For me this is critical error. 3. Moreover I strongly disagree with the sentence that the "fix would be to remove INLINE pragma" because this leaves us in a world where GHC performance is completely unknown and we have to randomly enable / disable things hoping that it will magically get better. I suspect @sgraf that you didn't mean "fix" but instead a "dirty workaround for now", but I preferred to emphasize my worries regarding this matter. 4. Answering your question @simonpj, I completely understand that GHC is super-cautious about inlining things and making the code bigger, but that is exactly the reason why we can fine tune the behavior by telling GHC that we in reality want it to be inlined, right? Exactly this led me to use INLINE pragma here. When writing this code I know I will have here some very tight loops to be optimized and I know that no matter what it sohuld be inlined. 5. I'm surprised that `test1` is not eta expanded. How can I be sure my functions get eta expanded? I have read the `Note [Do not eta-expand PAPs]` but it's still not clear to me. What are the "invariants here". If I write high performance code should I always manually eta-expand functions? Should I rewrite it to `test1 = \t -> runTokenParser testGrammar1 t`? Please correct me if my thinking is wrong here. 6. Regarding the `test2`, specialization and over-specialising things. I see the problem and I don't know what approach would be good here. The only thing that is clear to me is that the change to code is so small, that nobody should expect such drastic performance changes and we should have a clear way of preventing such things from happening (again - invariant of how to write high performance code when we want to wrap some data in a compile-known constructor just to refactor things). 7. Looking at the source code I don't see any mention of the `SPEC` in GHC.Type. Where it cames from and where can I learn more about it? -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15519#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler