... | @@ -16,7 +16,6 @@ This is where we track various efforts to characterize and improve the performan |
... | @@ -16,7 +16,6 @@ This is where we track various efforts to characterize and improve the performan |
|
|
|
|
|
- Significantly improved in memory usage from [\#10370](https://gitlab.haskell.org//ghc/ghc/issues/10370), but worse at overall wall-clock time!
|
|
- Significantly improved in memory usage from [\#10370](https://gitlab.haskell.org//ghc/ghc/issues/10370), but worse at overall wall-clock time!
|
|
- [\#10370](https://gitlab.haskell.org//ghc/ghc/issues/10370): OpenGLRaw
|
|
- [\#10370](https://gitlab.haskell.org//ghc/ghc/issues/10370): OpenGLRaw
|
|
- [\#8095](https://gitlab.haskell.org//ghc/ghc/issues/8095): TypeFamilies painfully slow
|
|
|
|
|
|
|
|
- [\#9557](https://gitlab.haskell.org//ghc/ghc/issues/9557): Deriving instances is slow
|
|
- [\#9557](https://gitlab.haskell.org//ghc/ghc/issues/9557): Deriving instances is slow
|
|
- [\#8731](https://gitlab.haskell.org//ghc/ghc/issues/8731): long compilation time for module with large data type and partial record selectors
|
|
- [\#8731](https://gitlab.haskell.org//ghc/ghc/issues/8731): long compilation time for module with large data type and partial record selectors
|
... | @@ -30,6 +29,22 @@ This is where we track various efforts to characterize and improve the performan |
... | @@ -30,6 +29,22 @@ This is where we track various efforts to characterize and improve the performan |
|
|
|
|
|
[ https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Compile-time+performance+bug](https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Compile-time+performance+bug)
|
|
[ https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Compile-time+performance+bug](https://ghc.haskell.org/trac/ghc/query?status=!closed&failure=Compile-time+performance+bug)
|
|
|
|
|
|
|
|
### Coercion pile-up
|
|
|
|
|
|
|
|
|
|
|
|
One theme that seems to pop up rather often is the production of Core with long strings of coercions, with the size scaling non-linearly with the size of the types in the source program. This i
|
|
|
|
|
|
|
|
- [\#8095](https://gitlab.haskell.org//ghc/ghc/issues/8095): TypeFamilies painfully slow
|
|
|
|
|
|
|
|
- Here a recursive type family instance leads to quadratic blow-up of coercions
|
|
|
|
- [\#7428](https://gitlab.haskell.org//ghc/ghc/issues/7428): GHC compile times are seriously non-linear in program size
|
|
|
|
|
|
|
|
- Here a CPS'd State monad is leading to a quadratic blowup in Core size over successive simplifier iterations
|
|
|
|
- [\#5642](https://gitlab.haskell.org//ghc/ghc/issues/5642): Deriving Generic of a big type takes a long time and lots of space
|
|
|
|
|
|
|
|
|
|
|
|
One possible solution (proposed in [\#8095](https://gitlab.haskell.org//ghc/ghc/issues/8095)) is to eliminate coercions from the Core AST during usual compilation, instead only including them when we want to lint the Core.
|
|
|
|
|
|
## tests/perf/compiler\` results
|
|
## tests/perf/compiler\` results
|
|
|
|
|
|
### 7.6 vs 7.8
|
|
### 7.6 vs 7.8
|
... | | ... | |