Playground warmup is very slow

[shmish111]

We are being affected by haskell-hint/hint#56 so I will look into:

1. Will GHC 8.6 fix this?
2. Will using GHCI rather than hint fix this

[michaelpj]

I did some debugging of this a while ago (I think it's the same issue that's affecting our doctests). You can gdb attach to the process and get a stack trace, which I think indicated that it was definitely something in module loading.

However, I also had a look and I'm pretty sure we're using dynamically linked libraries, but I'm not an expert on this so I might have got this wrong (I think I just looked at the output of ldd on things, and it looked like there were lookup paths).

[shmish111]

Hmm, currently we can't use ghc 8.6 because of eskimor/servant-subscriber#19 so I will try a hint-only project to see at least if this will solve it in the future. Try ghci first though.

[michaelpj]

If that's the only blocker we could fork and fix, and add the fork as a git dependency.

[shmish111]

So, with servant subscriber fixed (I have submitted a PR) we are now blocked by https://ghc.haskell.org/trac/ghc/ticket/16104 which will no doubt take quite a few months before it is available to us (we want it in a stackage LTS really). See #461

I will move on to GHCI

[shmish111]

so on a machine where the server warmup takes almost 1 minute, ghci loads files in less than 1 second and takes less to start up. This is using the same ghc lib dir as hint is using. The only difference between this test and hint is that hint is running within a Haskell process which maybe causes some contention in the way ghc is loading things. I think this test is successful enough to move on to trying to embed ghci in the haskell server and see what happens.

[michaelpj]

Yes, that makes sense - it's also the case that I've been able to use ghci-as-a-process just fine in the projects where the doctests are slow, so it does seem to be something about using it as a library.

[mchakravarty]

This is bizarre in so far as ghci also just uses GHC as a library. (However, I am not objecting to the plan. Tracking down whether it is due to hint or some other incidental difference in how GHC gets configured may be very time consuming and maybe just going for the simple solution is the easiest approach and simplifies maintenance in the long run.)

[shmish111]

Currently I'm actually looking at runghc as dealing with a single session of ghci will be very complicated in terms of parsing the output. A quick play around of runghc on the command line with some of our contracts showed it to have an unnoticeable performance difference and running a single command per server request is much easier

[shmish111]

This is fixed by moving from hint to runghc

[krisajenkins]

This is now merged, tested and pending release. See #514.

[mpickering]

FWIW, the other workaround is to compile the executable which uses the GHC API using -dynamic.

[shmish111]

@mpickering oh really, wow. I think runghc is currently a better solution anyway as it allows spawning as many processes as we require and seems to have almost no overhead.

[shmish111]

@mpickering can you explain why? or is it just magic :D

[mpickering]

It's not clear yet but it's something to do with using the system linker vs the linker built into GHC.

See https://gitlab.haskell.org/ghc/ghc/issues/15524