adding whole-project loading - #5002
Conversation
d0b01cc to
b29e37a
Compare
|
@fendor let me know if you have a better field name than |
| <*> o .:? "sessionLoading" .!= sessionLoading defValue | ||
| <*> loadingPref o | ||
| <*> o .:? "linkSourceTo" .!= linkSourceTo defValue |
There was a problem hiding this comment.
We should definitely not deprecate sessionLoading without warning first. :) Happy to make sure that the next HLS announcement on the Haskell blog includes it.
|
Can we open an issue proposing what the changes to HLS are? |
fendor
left a comment
There was a problem hiding this comment.
Changes look good to me, primarily a question of UX and naming
|
Created issue #5005 to document design |
There was a problem hiding this comment.
Good work so far @Saizan, I'm seeing a couple of things that I'd like you to clarify:
-
There seems to be both
needed-onlyandonly-needed, is that desired? We should probably stick withmulti: needed-only. -
You seem to have introduced the double usage of
multipleComponents(full words, plural) andmultiComponent(abbreviated, singular). Please stay withmultipleComponents:
[ show @String old_value ++ " (deprecated)"
==> | old_value <- ["singleComponent","multiComponent"]
]- I feel like there is a similar disparity between "session loading" and "component loading" but maybe I'm wrong?
|
@Kleidukos thanks for catching that, decided to give a name to these strings, see last commit. |
|
@Saizan Do you know if we can expect an increase in memory consumption when enabling this feature? Would you mind sharing memory profiles before / after your patch? Not a blocker but this could certainly bring light on stuff we could work on afterwards. :) |
|
@Kleidukos you mean compared to Or would you like to know how much memory extra "unneeded" components amount to? I would assume it's going to be fairly dependent on their composition, do you have a project in mind we could take as a benchmark? Otherwise I suppose the natural choice is HLS itself. |
|
@Saizan Starting with HLS itself is not a bad choice at all! Basically what I'm interested in is what the average end-user can expect in terms of resource consumption after upgrading, with a project that has multiple packages.
Something like this, yes. Basically if you have a workflow of "navigating a codebase with multiple components / packages in a project, what does that change for the end-user in terms of reactivity and does that blow up their memory usage". :) |
|
Here's some measurements. Too avoid anything too complicated I ran
Each time I set TLDR: memory can differ by ~1-2GB, either can come up on top. Excluded targetsTo avoid the cabal repl bug with To make sure ResultsAll FilesHere $FILES is set to all files from units that were not excluded. hls-needed-onlyFirst run Second run hls-whole-projectFirst run Second run
|
|
Fulls logs and inputs in the tarball. One thing to be careful about when testing is that shared libraries make it complicated to have both versions of hls live at once, so I recommend to first collect all your numbers for one version and then the other. Or I guess someone should add a --config flag to |
cf271c1 to
80bf872
Compare
fendor
left a comment
There was a problem hiding this comment.
I applied some final tweaks, now I am happy with it!
Performance numbers have been delivered!
renamed "sessionLoading" config to "componentsLoading" deprecated old values in favor of: "single", "multi: needed-only", "multi: whole-project" Upgrade to hie-bios 0.21.0.0
Updates hls to hie-bios 0.21 and takes advantage of its new LoadMode to add "whole project" components loading: loads all components specified in the cradle from the start, regardless of which files are open.
TODO: