Current implementation does the simplest thing possible: it restarts GHC to serve every request; technically: every request implies a separate call to
runGhc. Note that a request here means building one Bazel target, that is, a Haskell binary or Haskell library.
Even simple “full restart” approach brings 10–15% speedup on a certain simple benchmark project. We should do better though. There are several possible avenues for improvement.
Idea 1: Caching (Parts of) GHC Startup
There should be a way to profit from the warm startup vs the cold one. One idea I've been pursuing specifically: cache loading package databases. It requires GHC to export some more internals in the API. Subject to a GHC ticket/proposal.
Idea 2: Incremental Builds
A worker should be able to cache resulting artifacts. Later on, when it recieves a request to build an input with a known
digest (hash), it should return the corresponding artifact straight away.
This idea implemented in several other workers (Swift, Kotlin,
rules_scala_anex), but not in all (or majority) of them.
should show off a simple example of building
cabal new-build still have rough corners, you have to install stuff manually before calling it. There are two steps.
cabal new-install proto-lens-protoc
~/.cabal/bin should be in your path)