#11371: Bogus in-scope set in substitutions -------------------------------------+------------------------------------- Reporter: simonpj | Owner: niteria Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Compiler | Version: 7.10.3 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: #11360 | Differential Rev(s): phab:D1792, Wiki Page: | phab:D1801, phab:D1802 -------------------------------------+------------------------------------- Comment (by niteria): I've done some profiling today and I've optimized `piResultTys` a bit. Here are the results (this is built with prof): {{{ Benchmark name baseline with-inscope without-inscope tests/alloc/T5030 1084862416 1198020320 1084861344 tests/alloc/T9872a 5426538936 5576679896 5426504344 tests/alloc/T9872b 7807323280 8022344352 7728326496 tests/alloc/T9872c 7113767856 7405191768 7113729216 }}} `baseline` is the current incorrect implementation that doesn't compute the in-scope sets. `with-inscope` is https://phabricator.haskell.org/P97 - an implementation where the `coreView` that was hidden in `splitPiTy_maybe` and in `getTyVar_maybe` is done only once and both are inlined. This is the hint that I got from profiling, there was a significant difference in bytes allocated by `splitPiTy_maybe`. `without-inscope` is https://phabricator.haskell.org/P95 - a version of `with-inscope` that's doesn't compute the in-scope sets. So `without-inscope` is a strict, but small improvement over `baseline` performance wise, but the cost of computing the `in-scope` sets is non- trivial, so the correct version has a performance penalty. Are we willing to accept it in the name of correctness? The correct version has to do more work. The hot path is `cmpTypeX -> typeKind -> piResultTys`, I believe `cmpTypeX` already has the relevant free vars in the `env`, so passing them down is what I'll try to do next. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11371#comment:30 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler