Skip to content
  • Krzysztof Gogolewski's avatar
    Various performance improvements · 6cb84c46
    Krzysztof Gogolewski authored and Ben Gamari's avatar Ben Gamari committed
    This implements several general performance improvements to GHC,
    to offset the effect of the linear types change.
    
    General optimisations:
    - Add a `coreFullView` function which iterates `coreView` on the
      head. This avoids making function recursive solely because the
      iterate `coreView` themselves. As a consequence, this functions can
      be inlined, and trigger case-of-known constructor (_e.g._
      `kindRep_maybe`, `isLiftedRuntimeRep`, `isMultiplicityTy`,
      `getTyVar_maybe`, `splitAppTy_maybe`, `splitFunType_maybe`,
      `tyConAppTyCon_maybe`). The common pattern about all these functions
      is that they are almost always used as views, and immediately
      consumed by a case expression. This commit also mark them asx `INLINE`.
    - In `subst_ty` add a special case for nullary `TyConApp`, which avoid
      allocations altogether.
    - Use `mkTyConApp` in `subst_ty` for the general `TyConApp`. This
      required quite a bit of module shuffling.
      case. `myTyConApp` enforces crucial sharing, which was lost during
      substitution. See also !2952 .
    - Make `subst_ty` stricter.
    - In `eqType` (specifically, in `nonDetCmpType`), add a special case,
      tested first, for the very common case of nullary `TyConApp`.
      `nonDetCmpType` has been made `INLINE` otherwise it is actually a
      regression. This is similar to the optimisations in !2952.
    
    Linear-type specific optimisations:
    - Use `tyConAppTyCon_maybe` instead of the more complex `eqType` in
      the definition of the pattern synonyms `One` and `Many`.
    - Break the `hs-boot` cycles between `Multiplicity.hs` and `Type.hs`:
      `Multiplicity` now import `Type` normally, rather than from the
      `hs-boot`. This way `tyConAppTyCon_maybe` can inline properly in the
      `One` and `Many` pattern synonyms.
    - Make `updateIdTypeAndMult` strict in its type and multiplicity
    - The `scaleIdBy` gets a specialised definition rather than being an
      alias to `scaleVarBy`
    - `splitFunTy_maybe` is given the type `Type -> Maybe (Mult, Type,
      Type)` instead of `Type -> Maybe (Scaled Type, Type)`
    - Remove the `MultMul` pattern synonym in favour of a view `isMultMul`
      because pattern synonyms appear not to inline well.
    - in `eqType`, in a `FunTy`, compare multiplicities last: they are
      almost always both `Many`, so it helps failing faster.
    - Cache `manyDataConTy` in `mkTyConApp`, to make sure that all the
      instances of `TyConApp ManyDataConTy []` are physically the same.
    
    This commit has been authored by
    * Richard Eisenberg
    * Krzysztof Gogolewski
    * Arnaud Spiwack
    
    Metric Decrease:
        haddock.base
        T12227
        T12545
        T12990
        T1969
        T3064
        T5030
        T9872b
    
    Metric Increase:
        haddock.base
        haddock.Cabal
        haddock.compiler
        T12150
        T12234
        T12425
        T12707
        T13035
        T13056
        T15164
        T16190
        T18304
        T1969
        T3064
        T3294
        T5631
        T5642
        T5837
        T6048
        T9020
        T9233
        T9675
        T9872a
        T9961
        WWRec
    6cb84c46