Poor performance when building many packages

[tfausak]

I was curious about the relative performance of lots of declarations vs. modules vs. packages. I wrote a benchmark that creates a Stack project with some number of those things and times how long it takes to build. The raw results from 1 to 64 are available in this Google doc. Here they are graphed:

As you can see, adding declarations or modules does not significantly increase the build time. However, the build time is linearly correlated to the number of packages. I expected this to a certain extent because packages do a lot more than modules or declarations. I didn't expect each package to add 0.6 seconds to the build time, though.

I know this isn't a problem per se, but it's unfortunate that building 10 packages incurs a 6 second performance penalty. I don't have any insight into why Stack takes that long. Is this worth exploring, or is this just the price that must be paid to compile a Haskell package?

---

For this benchmark the declarations, modules, and packages are as simple as possible. Here's what a module would look like:

module P0m0 where
p0m0d0 :: ()
p0m0d0 = ()

And here's a package definition:

name: p0
version: 1.2.3
build-type: Simple
cabal-version: >= 1.10
library
  default-language: Haskell98
  build-depends: base
  exposed-modules:
    P0m0

And here's the Stack config:

resolver: lts-7.12
packages:
  - p0

[tfausak]

I looked into this a little more this morning. I discovered that, perhaps obviously, this isn't a problem with Stack per se. I did a --verbose build with 64 packages and looked for the most time-consuming parts. It's almost entirely stuff like this:

2016-12-17 09:42:33.849443: [debug] Process finished in 1112ms: /home/taylor/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.1.0_ghc-8.0.1.20161117 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.1.0 build lib:p59 --ghc-options " -ddump-hi -ddump-to-file"

In other words, cabal build. The next worst offender is cabal configure:

2016-12-17 09:41:51.361515: [debug] Process finished in 640ms: /home/taylor/.stack/setup-exe-cache/x86_64-linux/Cabal-simple_mPHDZzAJ_1.24.1.0_ghc-8.0.1.20161117 --builddir=.stack-work/dist/x86_64-linux/Cabal-1.24.1.0 configure --with-ghc=/home/taylor/.stack/programs/x86_64-linux/ghc-8.0.1.20161117/bin/ghc --with-ghc-pkg=/home/taylor/.stack/programs/x86_64-linux/ghc-8.0.1.20161117/bin/ghc-pkg --user --package-db=clear --package-db=global --package-db=/home/taylor/.stack/snapshots/x86_64-linux/lts-7.12/8.0.1.20161117/pkgdb --package-db=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/pkgdb --libdir=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/lib --bindir=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/bin --datadir=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/share --libexecdir=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/libexec --sysconfdir=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/etc --docdir=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/doc/p0-1.2.3 --htmldir=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/doc/p0-1.2.3 --haddockdir=/home/taylor/Documents/dc8b6a05d3c4f55d8f6c50364de2d852/scratch/.stack-work/install/x86_64-linux/lts-7.12/8.0.1.20161117/doc/p0-1.2.3 --dependency=base=base-4.9.1.0 --enable-tests --enable-benchmarks

I think that improving the performance of building packages will require hacking on Cabal.

[tfausak]

I wrote a benchmark for this behavior using Cabal. The takeaway is that building a package with a cold cache takes about 1.5 seconds. With a warm cache it's about 0.5 seconds. Since this is a problem with Cabal, I opened an issue there: haskell/cabal#4175.