Re: [GHC] #15646: ghci takes super long time to find the type of large fractional number

1 Dec 2018

      #15646: ghci takes super long time to find the type of large fractional number
-------------------------------------+-------------------------------------
        Reporter:  Johannkokos       |                Owner:
                                     |  JulianLeviston
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.6.1
       Component:  GHCi              |              Version:  8.4.3
      Resolution:                    |             Keywords:  newcomer
Operating System:  Unknown/Multiple  |         Architecture:
 Type of failure:  Compile-time      |  Unknown/Multiple
  performance bug                    |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:  #5692             |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by JulianLeviston):

 Ok, so I compiled and added in the line:

 {{{pprTrace "..." (text "litI:" <+> ppr litI <+>  text "litE:" <+> ppr
 litE) $ pure ()}}}

 ... however that's in `MatchLit`, so doesn't get executed when
 typechecking, only when evaluating. Makes sense because if I typecheck, I
 still get the slow behaviour, but if I evaluate, I get that error (coz I
 still haven't updated the location of `mkRational` yet).

 So, this also seems correct, given I have made zero changes in the
 typechecker so far. So I'm looking in to that.

 I hope I'm on the right track. I ran it with `./inplace/bin/ghc-stage2 -e
 ":t 1e289" -ddump-parsed-ast` and it responded with something that ended
 with:

 {{{
 ==================== Parser AST ====================

 (Just
  ({ <interactive>:1:1-5 }
   (BodyStmt
    (NoExt)
    ({ <interactive>:1:1-5 }
     (HsOverLit
      (NoExt)
      (OverLit
       (NoExt)
       (HsFractional
        (FL
         (SourceText
          "1e289")
         (False)
         (1)
         (289)
         (Base10)))
       (HsLit
        (NoExt)
        (HsString
         (SourceText
          "noExpr")
         {FastString: "noExpr"})))))
    (SyntaxExpr
     (HsLit
      (NoExt)
      (HsString
       (NoSourceText)
       {FastString: "noSyntaxExpr"}))
     []
     (WpHole))
    (SyntaxExpr
     (HsLit
      (NoExt)
      (HsString
       (NoSourceText)
       {FastString: "noSyntaxExpr"}))
     []
     (WpHole)))))
 }}}

 And, seeing `HsOverLit` in this output, and looking at `tcExpr` in
 `compiler/typecheck/TcExpr.hs`, it seems to match the `HsOverLit` clause,
 which calls `newOverloadedLit` from `compiler/typechecker/Inst.hs`, which
 I'm not 100% sure, but it seems to be *not* matching on a short cut
 clause, and so applying `newNonTrivialOverloadedLit`.

 I'll take another pass at understanding it all again tomorrow.

-- 
Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15646#comment:62
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler