Cabal-install is twice as fast as Stack (on OS X with lots of packages: in stack.yaml) #2041
Comments
|
Interesting, thanks for the test case. You're probably on the right track that it's related to dirtiness checking thousands of files. It should be possible to do dirtiness checking only for packages that are actually demanded by cabal-install doesn't need to do this work, because you need to build each local package independently. So you're already telling it "ignore changes in those other packages". I guess there could be some sort of |
|
How about including a dirty mark for each package and having:
So Leksah though would call As a bonus both |
|
So far we have avoided any sort of configuration state - it's all in the stack.yaml or the immediate CLI. This makes things more reproducible and reliable. This would be a lot of added complexity to handle a rare case. How about we have |
|
Having It would be nice though to be able to persist the dirty state somehow (so that restarting Leksah does not forget what packages were dirty). Is there a good way to get a timestamp for the last successful build of a package? I figure we might be able to do Then we could find all the packages Leksah needs to pass to |
|
If you want leksah's use of stack to be stateful, you're going to need to store state. I don't think there's a good way to get a timestamp for the last successful build - could go digging around for timestamps in dist, though. |
Yep, that is fine
I think we can get it from |
|
Note that currently logs are not outputted in the case that the build output goes to the console - see the recent discussion #2045 |
|
This still seems to be a significant issue. I have a faster machine now, but stack is still slower than cabal-install (8.348s vs 2.503s). |
|
Your stack.yaml is using a bunch of local packages which . Since these packages are local and may be modified, it is collecting a list of all files. Some of these packages are automatically generated and have many hundreds of modules. Unfortunately, this files collection code is currently inefficient - this is discussed and tracked in the latter part of #1235 , so closing this as a dupe of that. |
I recently ported Leksah from Gtk2Hs to haskell-gi. When I started out I thought I would try using Stack, but it was very slow and I did not have time to investigate why (instead I went back to using cabal-install). The port is done now and I have time to help figure out what is going on.
To reproduce the issue I follow the instructions to build Leksah from GitHub with Cabal-install. I then ran
stack buildto also build it with Stack. I added an error to one of the source files to compare the time it takescabal buildandstack buildto find the error. Stack is taking an extra 10-12 seconds on my 3 year old MacBook Pro with SSD.I suspect it might be related to the large number of
packages:in thestack.yamlfile and perhaps the large number of source files in some of those packages (some have over a thousand hs and hsc files).Cabal-install does not have to check all of those because Leksah tells it what package to build (there does not seem to be a stack command to build one package without checking the others).
Here it is with verbose logging
The text was updated successfully, but these errors were encountered: