Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stack is extremely slow for Cabal, due to custom setup script #1041

Closed
ezyang opened this issue Sep 24, 2015 · 2 comments
Closed

Stack is extremely slow for Cabal, due to custom setup script #1041

ezyang opened this issue Sep 24, 2015 · 2 comments
Assignees
Milestone

Comments

@ezyang
Copy link

ezyang commented Sep 24, 2015

Stack uses runghc to run custom Setup scripts, which for Cabal means that builds are unusably slow as all of Cabal is interpreted. In these cases, I just stop having Cabal bootstrap itself because Stack is so slow in this case. I don't know, can Stack maybe build the script or something?

@snoyberg snoyberg added this to the P2: Should milestone Sep 24, 2015
@snoyberg
Copy link
Contributor

In principle this should be fine, there are just questions of:

  1. Do we make it the default?
  2. Where do we store the generate executable?

The relevant bit of code is at:

esetupexehs <-

@mgsloan
Copy link
Contributor

mgsloan commented Sep 25, 2015

If Setup.hs only needed to be run once, then running it in the interpreter would be a clear win over compiling it. The issue isn't that interpreted Cabal is too slow - it isn't doing all that much heavy lifting. The issue is that it gets run multiple times, and it gets reloaded into the interpreter each time. Interpreting Cabal once to build it is going to be much faster than building it twice.

Here's an approach that's substantially faster way to build Cabal than either cabal install or stack install:

mgsloan@computer:~/oss/haskell/cabal/Cabal$ ghci Setup.hs
...
*Main> :set args configure
*Main> main
Configuring Cabal-1.22.4.0...
*Main> :set args build
*Main> main
Building Cabal-1.22.4.0...

I'm not sure if the complexity of managing interpreter processes is worth the performance gain, so I'm not really proposing this. Just pointing it out since I thought of it.

Anyway, one way or another I am in favor of doing something about this. It would be very nice for GHCJS, where the interpreter is still WIP. In that circumstance it's even worse, because Setup.hs gets compiled each time it's run. It only affects packages with custom scripts, but this is pretty bad.

@snoyberg snoyberg self-assigned this Oct 9, 2015
snoyberg added a commit that referenced this issue Oct 10, 2015
Compile custom Setup.hs instead of interpreting them (fixes #1041)
dysinger added a commit that referenced this issue Nov 13, 2015
* master: (59 commits)
  Ignore global database when copying precompiled packages #1146
  Revert an unneeded change to 'runAndLog'
  Remove old GHCJS unpack directory if it exists
  Allow "stack setup ghcjs-0.1.0.20150924_ghc-7.10.2"
  Properly unzip GHCJS on windows (stack setup)
  Consider user-specified package flags in stack solver #1071
  Fix a warning
  Colored build status in filewatch mode
  Add NixOS to 'How to install'.
  Include NixOS information #1118
  Style improvements for Docker compatibility check
  Fix `awaiting pr` label link
  Fix GHC 7.8 build
  Docker: check host's stack compatibility by attempting to run in container and caching the result (#974)
  Fix formatting in `explicit-setup-deps` section
  Provide more information about changed files
  Compile custom Setup.hs instead of interpreting them (fixes #1041)
  Detect when hpc report gives trivial 100% #1009
  Unified coverage report #579
  Recommend extra-dep in yaml_configuration.yml
  ...
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants