[Git][ghc/ghc][wip/fendor/ifacetype-delay-serialisation] 8 commits: Add deduplication table for `IfaceType`

[Hannes Siebenhandl (@fendor)]

Hannes Siebenhandl pushed to branch wip/fendor/ifacetype-delay-serialisation at Glasgow Haskell Compiler / GHC


Commits:
03084bcc by Matthew Pickering at 2024-04-15T11:52:42+02:00
Add deduplication table for `IfaceType`

The type `IfaceType` is a highly redundant, tree-like data structure.
While benchmarking, we realised that the high redundancy of `IfaceType`
causes high memory consumption in GHCi sessions.
We fix this by adding a deduplication table to the serialisation of
`ModIface`, similar to how we deduplicate `Name`s and `FastString`s.
When reading the interface file back, the table allows us to automatically
share identical values of `IfaceType`.

This deduplication has the beneficial side effect to additionally reduce
the size of the on-disk interface files tremendously. On the agda code
base, we reduce the size from 28 MB to 16 MB. When `-fwrite-simplified-core`
is enabled, we reduce the size from 112 MB to 22 MB.

We have to add an `Ord` instance to `IfaceType` in order to store it
efficiently for look up operations. This is mostly straightforward, we
change occurrences of `FastString` with `LexicalFastString` and add a
newtype definition for `IfLclName = LexicalFastString`.

We also add IfaceType deduplication table to .hie serialisation and
refactor .hie file serialisation to use the same infrastrucutre as
`putWithTables`.

Bump haddock submodule for `IfLclName` newtype changes.

- - - - -
d64cfe21 by Matthew Pickering at 2024-04-15T11:54:14+02:00
Add some tests to check for size of interface files when serialising
various types

- - - - -
5610aa86 by Matthew Pickering at 2024-04-15T11:54:14+02:00
WIP: TrieMap for IfaceType

Bump haddock submodule

- - - - -
2a19c5c5 by Fendor at 2024-04-15T11:54:15+02:00
WIP: CI results for Data.Map deduplication

- - - - -
292f6f81 by Matthew Pickering at 2024-04-15T11:54:15+02:00
Only share IfaceTyConApp

- - - - -
c5077818 by Fendor at 2024-04-15T11:56:54+02:00
Share duplicated values in ModIface after generation

This helps keeping down the peak memory usage while compiling in
`--make` mode.

- - - - -
003ac7de by Matthew Pickering at 2024-04-15T12:01:15+02:00
Delay deserialisation of `IfaceType` until needed

Introduces `IfaceSerialisationType` which holds onto a ByteString
in-memory. All `IfaceType`'s are first deserialised to
`IfaceSerialisationType`, so no actual deserialisation happens until the
value is requested. Then, we decode `IfaceSerialisationType` into the
real `IfaceType` value.

- - - - -
939a1c74 by Matthew Pickering at 2024-04-15T12:01:17+02:00
MP fixes

- - - - -


30 changed files:

- compiler/GHC/Core/Map/Expr.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Data/FastString.hs
- compiler/GHC/Data/TrieMap.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Iface/Binary.hs
- compiler/GHC/Iface/Decl.hs
- compiler/GHC/Iface/Env.hs
- compiler/GHC/Iface/Ext/Binary.hs
- compiler/GHC/Iface/Ext/Utils.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/Iface/Recomp/Binary.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Type.hs
- + compiler/GHC/Iface/Type/Map.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Stg/CSE.hs
- compiler/GHC/StgToJS/Object.hs
- compiler/GHC/Tc/Types.hs
- compiler/GHC/Types/Basic.hs
- compiler/GHC/Types/Var.hs
- compiler/GHC/Unit/Module/ModIface.hs
- compiler/GHC/Utils/Binary.hs
- compiler/Language/Haskell/Syntax/Type.hs
- compiler/Language/Haskell/Syntax/Type.hs-boot
- compiler/ghc.cabal.in
- + testsuite/tests/iface/IfaceSharingFastString.hs
- + testsuite/tests/iface/IfaceSharingIfaceType.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2076ed5d2193fef27ec89fb56da506d37921bca3...939a1c746f49bab04821ae7615bccb8005020519

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2076ed5d2193fef27ec89fb56da506d37921bca3...939a1c746f49bab04821ae7615bccb8005020519
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20240415/6601e60e/attachment.html>