4 ms·

> If care isn’t taken, projects can quickly devolve to become unmanageably slow to compile, usually the problem is avoidable with some care. This is currently

> If care isn’t taken, projects can quickly devolve to become unmanageably slow to compile, usually the problem is avoidable with some care. This is currently not the case. It's sometimes not avoidable at all. Compile times are a real concern right now. A GHC maintainer has even confessed to it being a very significant issue. https://www.reddit.com/r/haskell/comments/45q90s/is_anything_being_done_to_remedy_the_soul/czzmbt1 https://www.reddit.com/r/haskell/comments/45q90s/is_anything...

mbrock 11y ago
As a big Haskell fan, the memory usage of GHC on certain modules is one reason I don't use it as much as I'd want. Several times I've had to double my swap file or increase the RAM on a VPS to compile some Haskell package, and I don't want to impose that on users of my software. Usually people don't build Haskell on their servers, just deploy binaries, but I do all my work on a VPS right now. Anyway, compiler resource use is a pretty big factor for me.
- brobinson 11y ago
  My only experience with compiling Haskell on a VPS involved over 100gb of swap I/O happening during a >24 hours compilation of LambaBot on a 512mb machine.
  - mbrock 11y ago
    In a utilitarian sense, the pain caused by this could probably be greatly reduced with a robust system of cached binary builds. Right now we're all just compiling the same dependency trees over and over again, wasting cycles. So since making GHC drastically more efficient is an enormous problem, maybe getting Stack/Cabal to download binary caches would be the best way to go forward. There's a Nix build server that offers all of Stackage in binary form. That really takes a lot of pain away, at least if you're on a supported architecture (x86_64, I guess). But it's run by a volunteer individual, I think. Of course, Debian and others have been packaging Haskell binaries forever, but I don't think most people want to deal with distribution packages for development. I'm sure there are lots of discussions about this in other places... All I've found from my random googling is this post which is about binary sharing on the same computer: https://www.fpcomplete.com/blog/2015/09/stack-more-binary-package-sharing https://www.fpcomplete.com/blog/2015/09/stack-more-binary-pa...
    - rybosome 11y ago
      http://bazel.io http://bazel.io I've never used the open-source variant, but caching of intermediate targets allowing for speedy incremental builds is a big theme.
    - enigmo 11y ago
      I've seen Stack download prebuilt binaries for some packages but build others... always having prebuilt versions of text/aeson/vector/lens/etc would definitely speed up resolver upgrades.

mbrock 11y ago

As a big Haskell fan, the memory usage of GHC on certain modules is one reason I don't use it as much as I'd want. Several times I've had to double my swap file or increase the RAM on a VPS to compile some Haskell package, and I don't want to impose that on users of my software. Usually people don't build Haskell on their servers, just deploy binaries, but I do all my work on a VPS right now. Anyway, compiler resource use is a pretty big factor for me.

brobinson 11y ago
My only experience with compiling Haskell on a VPS involved over 100gb of swap I/O happening during a >24 hours compilation of LambaBot on a 512mb machine.
- mbrock 11y ago
  In a utilitarian sense, the pain caused by this could probably be greatly reduced with a robust system of cached binary builds. Right now we're all just compiling the same dependency trees over and over again, wasting cycles. So since making GHC drastically more efficient is an enormous problem, maybe getting Stack/Cabal to download binary caches would be the best way to go forward. There's a Nix build server that offers all of Stackage in binary form. That really takes a lot of pain away, at least if you're on a supported architecture (x86_64, I guess). But it's run by a volunteer individual, I think. Of course, Debian and others have been packaging Haskell binaries forever, but I don't think most people want to deal with distribution packages for development. I'm sure there are lots of discussions about this in other places... All I've found from my random googling is this post which is about binary sharing on the same computer: https://www.fpcomplete.com/blog/2015/09/stack-more-binary-package-sharing https://www.fpcomplete.com/blog/2015/09/stack-more-binary-pa...
  - rybosome 11y ago
    http://bazel.io http://bazel.io I've never used the open-source variant, but caching of intermediate targets allowing for speedy incremental builds is a big theme.
  - enigmo 11y ago
    I've seen Stack download prebuilt binaries for some packages but build others... always having prebuilt versions of text/aeson/vector/lens/etc would definitely speed up resolver upgrades.