HIE file generation is inefficient
Generating HIE files eats up a lot of memory and takes a long time. There are at least two big parts to this:
- Every expression in the AST is desugared via
deSugarExprfor the purpose of extracting a type. GHC ends up doing the same work multiple times for the same nodes. Ex: in order to desugarHsApp _ fun arg, GHC desugars bothfunandarg, yet the HIE code doesn't cache that (so it ends up desugaringfunandargat least once more). - There is a lot of stuff being written into these HIE files, making them quite big (even after compressing/deduplicating type information). One data point: the largest HIE file at time of writing is
Parser.hie, which is 7.2MB, compared to just 58K forParser.hiQ Writing large files is naturally going to take up memory and be slow.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.7 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture |