[GHC] #12706: Collecting type info is slow
GHC
ghc-devs at haskell.org
Mon Oct 24 17:35:30 UTC 2016
#12706: Collecting type info is slow
-------------------------------------+-------------------------------------
Reporter: vshabanov | Owner:
Type: bug | Status: new
Priority: normal | Milestone:
Component: GHCi | Version: 8.0.1
Resolution: | Keywords:
Operating System: Unknown/Multiple | Architecture:
| Unknown/Multiple
Type of failure: None/Unknown | Test Case:
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s):
Wiki Page: |
-------------------------------------+-------------------------------------
Comment (by vshabanov):
I tried profiled compiler. Unfortunately I don't know GHC internals well
enough to fix it but, anyway, here are my findings.
Most time is spent in source:ghc/ghc/GHCi/UI/Info.hs
Half time is spent in `typecheckModule` call and another half in
`everythingAllSpans`.
First problem here is a bad `cacheInvalid` function. It checks file time
of object file, but there are no object files in GHCi. So types are always
collected for all modules instead of new/modified ones. I don't know how
to correctly check what files were recompiled but it's the first thing to
do to shorten "Collecting type info" phase. Clearing cache on `:l` in GHCi
is also necessary to free memory.
I'm also not sure about call to `typecheckModule`. Aren't modules already
type checked? Maybe it's possible to get type check results that were
already calculated.
Harder thing to do is to optimize `everythingAllSpans`. It uses SYB
approach to extract `LHsBind`, `LHsExpr` and `LPat` from
`TypecheckedSource = Bag (Located HsBindLR)`. It could be rewritten using
direct recursion over `HsBindLR` without `cast` and `gmapQ`. But it looks
like quite a big task.
--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12706#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the ghc-tickets
mailing list