Commits on Source (6)
-
Hannes Siebenhandl authored
The end goal is to dynamically add deduplication tables for `ModIface` interface serialisation. We identify two main points of interest that make this difficult: 1. UserData hardcodes what `Binary` instances can have deduplication tables. Moreover, it heavily uses partial functions. 2. GHC.Iface.Binary hardcodes the deduplication tables for 'Name' and 'FastString', making it difficult to add more deduplication. Instead of having a single `UserData` record with fields for all the types that can have deduplication tables, we allow to provide custom serialisers for any `Typeable`. These are wrapped in existentials and stored in a `Map` indexed by their respective `TypeRep`. The `Binary` instance of the type to deduplicate still needs to explicitly look up the decoder via `findUserDataReader` and `findUserDataWriter`, which is no worse than the status-quo. `Map` was chosen as microbenchmarks indicate it is the fastest for a small number of keys (< 10). To generalise the deduplication table serialisation mechanism, we introduce the types `ReaderTable` and `WriterTable` which provide a simple interface that is sufficient to implement a general purpose deduplication mechanism for `writeBinIface` and `readBinIface`. This allows us to provide a list of deduplication tables for serialisation that can be extended more easily, for example for `IfaceTyCon`, see the issue #24540 for more motivation. In addition to ths refactoring, we split `UserData` into `ReaderUserData` and `WriterUserData`, to avoid partial functions. Bump haddock submodule to accomodate for `UserData` split. ------------------------- Metric Increase: T21839c -------------------------
68d406f8 -
Hannes Siebenhandl authored
A `BinHandle` contains too much information for reading data. For example, it needs to keep a `FastMutInt` and a `IORef BinData`, when the non-mutable variants would suffice. Additionally, this change has the benefit that anyone can immediately tell whether the `BinHandle` is used for reading or writing. Bump haddock submodule BinHandle split.
026372f7 -
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`. Bump haddock submodule for `IfLclName` newtype changes.
12a3a5d5 -
Hannes Siebenhandl authored
Refactor .hie file serialisation to use the same infrastrucutre as `putWithTables`.
4ed1ed63 -
Bump haddock submodule
c4a518b4 -
Hannes Siebenhandl authored829f88c9
Showing
- compiler/GHC/Core/Map/Expr.hs 3 additions, 0 deletionscompiler/GHC/Core/Map/Expr.hs
- compiler/GHC/Core/TyCo/Rep.hs 2 additions, 2 deletionscompiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/CoreToIface.hs 13 additions, 13 deletionscompiler/GHC/CoreToIface.hs
- compiler/GHC/Data/FastString.hs 4 additions, 1 deletioncompiler/GHC/Data/FastString.hs
- compiler/GHC/Data/TrieMap.hs 82 additions, 11 deletionscompiler/GHC/Data/TrieMap.hs
- compiler/GHC/Iface/Binary.hs 248 additions, 74 deletionscompiler/GHC/Iface/Binary.hs
- compiler/GHC/Iface/Decl.hs 3 additions, 4 deletionscompiler/GHC/Iface/Decl.hs
- compiler/GHC/Iface/Env.hs 7 additions, 8 deletionscompiler/GHC/Iface/Env.hs
- compiler/GHC/Iface/Ext/Binary.hs 81 additions, 98 deletionscompiler/GHC/Iface/Ext/Binary.hs
- compiler/GHC/Iface/Ext/Fields.hs 6 additions, 6 deletionscompiler/GHC/Iface/Ext/Fields.hs
- compiler/GHC/Iface/Ext/Utils.hs 3 additions, 3 deletionscompiler/GHC/Iface/Ext/Utils.hs
- compiler/GHC/Iface/Recomp.hs 3 additions, 3 deletionscompiler/GHC/Iface/Recomp.hs
- compiler/GHC/Iface/Recomp/Binary.hs 10 additions, 5 deletionscompiler/GHC/Iface/Recomp/Binary.hs
- compiler/GHC/Iface/Recomp/Flags.hs 3 additions, 3 deletionscompiler/GHC/Iface/Recomp/Flags.hs
- compiler/GHC/Iface/Syntax.hs 10 additions, 8 deletionscompiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Type.hs 99 additions, 53 deletionscompiler/GHC/Iface/Type.hs
- compiler/GHC/Iface/Type/Map.hs 180 additions, 0 deletionscompiler/GHC/Iface/Type/Map.hs
- compiler/GHC/IfaceToCore.hs 14 additions, 14 deletionscompiler/GHC/IfaceToCore.hs
- compiler/GHC/Stg/CSE.hs 4 additions, 0 deletionscompiler/GHC/Stg/CSE.hs
- compiler/GHC/StgToJS/Object.hs 21 additions, 20 deletionscompiler/GHC/StgToJS/Object.hs
compiler/GHC/Iface/Type/Map.hs
0 → 100644