don't repeatedly resolve common usage paths#6123
Merged
mpilgrem merged 1 commit intocommercialhaskell:masterfrom May 22, 2023
Merged
don't repeatedly resolve common usage paths#6123mpilgrem merged 1 commit intocommercialhaskell:masterfrom
mpilgrem merged 1 commit intocommercialhaskell:masterfrom
Conversation
Member
|
@dten, many thanks. I will review, but please bear with me. When it comes to 'architectural' matters, it takes me a little while to work through proposed changes. If another potential reviewer sees this and is more up to speed with the architecture, please do take the lead. |
Contributor
Author
|
sure thing 😃 by the way it looks likely the many |
Member
|
Looks good to me. |
mpilgrem
added a commit
that referenced
this pull request
May 23, 2023
Contributor
|
This patch moves my project from 1.5s on |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
For some large packages in our project
getPackageFileshas always quite a long time to complete, but it seems much worse in 9.4.x. (~7.5 seconds on my machine with stack 2.11 and ghc 9.4.5). Profiling showed it spent most of its time checking the the files fromusagesin.hifiles existed.When I checked what paths it was checking and how often I found that every
.hifile mentioned many.sofiles (~150) and each of these files was being checked it existed for each.hifile.This change attempts to collect up known resolution mappings whilst walking the
.hifiles so the resolution effort doesn't get repeated.This takes our slowest
getPackageFilescall down to ~3.6 seconds with the profile now showing the cost is mostly parsing the.hifiles.I've included before and after profile results where this was basically
stack test --file-watch --watch-allon an already build project to get to the point where it's ready to build new changes.before: note the wide sections calling forgivingResolveFile
after: those wide sections are now gone
the profiles also show stack does all the
getPackageFileswork twice which isn't ideal but i haven't looked into yet 👀