Typechecking cpkg's pkg-set.dhall doesn't finish

[sjakobi]

This looks like a regression since v1.25.0. I'm currently trying to find the commit that caused this.

[sjakobi]

72fd2ac seems to be at fault.

I used this ghci script in stack repl to bisect this:

import Data.Text.IO
text <- Data.Text.IO.readFile "/home/simon/src/cpkg/pkgs/pkg-set.dhall"
Right e =  exprFromText "" text
resolved <- loadRelativeTo "/home/simon/src/cpkg/pkgs" e
Prelude.putStrLn "Done resolving"
import Data.Either
isRight (typeOf resolved)

Before 72fd2ac this takes 10–15s. At 72fd2ac it just doesn't finish.

[Gabriella439]

@sjakobi: I can think of two options:

• See if we can fix the performance bug today by using the more efficient multi-let representation when type-checking
• If not, revert the change for this release and restore it afterwards once we fix the performance regression

[sjakobi]

I've been staring at 72fd2ac for a while, but I don't see what went wrong.

Profiling reveals that about 75% of time is spent in shift and subst.

Reverting seems like the pragmatic next step right now. Preserving 96921f0 might a bit tricky though.

[Gabriella439]

@sjakobi: You can revert 96921f0 if necessary, too

[sjakobi]

The reversions are at https://github.com/dhall-lang/dhall-haskell/compare/sjakobi/revert-simple-let.

echo https://raw.githubusercontent.com/vmchale/cpkg/d6649462f3a64ed8feea5dae39e183d2062a3b70/pkgs/pkg-set.dhall | cabal run -w ghc-8.6.5 -- dhall:dhall type

now finishes in a reasonable time. Yet the script still doesn't. I'm confused. :/

[Gabriella439]

@sjakobi: Maybe stack repl is using a stale version of the dhall package?

[sjakobi]

@Gabriel439 The difference is due to the way the file is accessed: Importing it works, but piping it to dhall is problematic.

To illustrate the issue more clearly:

On master, neither of the following commands finish when executed from cpkg's pkgs directory:

cat ./pkg-set.dhall | dhall type
echo ./pkg-set.dhall | dhall type

On the sjakobi/revert-simple-let branch

echo ./pkg-set.dhall | dhall type

succeeds quickly, but

cat ./pkg-set.dhall | dhall type

never finishes.

---

With v1.25.0, the difference can be observed, but is much less drastic:

echo ./pkg-set.dhall | dhall

takes about 8s on my machine.

cat ./pkg-set.dhall | dhall

takes about 14s.

[Gabriella439]

@sjakobi: So I know why importing the file by path rather than by contents is faster. This is because of the semi-semantic caching support that @EggBaconAndSpam added. What happens is that the first time you import ./pkgs-set.dhall as a local path then the fully resolved expression is automatically cached under ~/.dhall-haskell. Then subsequent imports of the same path go more quickly because they are cache hits

[Gabriella439]

@sjakobi: Oh, I think I know what the problem is. I'm willing to wager that it's due to removing this optimization as part of implementing dependent type support:

https://github.com/dhall-lang/dhall-haskell/pull/1164/files#diff-6b5593d90a4088272a0ea8057015520dL174

[sjakobi]

Ah, that makes sense. My whole investigation was bogus, as the script was still accessing the semantic cache! :/

Do you have an idea how the optimization could be brought back?

[Gabriella439]

@sjakobi: I don't think the optimization can be brought back. For example, none of the tests in the Prelude would type-check if we reinstated that optimization. The only way we can fix this for real is to finish the work described in #1129

I think we should just cut the release, communicate that there will be a performance regression for giant multi-let expressions and explain in the CHANGELOG how users can work around it (like by splitting up the multi-let expression). Then I will just implement #1129 myself after the release is cut