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
deSugarExpr
for 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 bothfun
andarg
, yet the HIE code doesn't cache that (so it ends up desugaringfun
andarg
at 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.hi
Q 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 |