Improve performance of LookupImpl.LookupAnalysis via pre-built index #1279
Conversation
This file contains 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
|
Overall LGTM, but if would be cool if we could include either a benchmark or some sample project that demonstrates the improvement. |
|
Here's the two recent CI benchmark results with & without the optimization: https://github.com/sbt/zinc/actions/runs/6773539163/job/18408627550 and https://github.com/sbt/zinc/actions/runs/6764410486/job/18382666918 Here's some excerpts: Without optimization: With optimization: So the numbers do seem to be smaller. However I don't know if the CI uses the same machine each time. If CI benchmark results is not truth-worthy enough, I can do testing locally on my laptop. |
|
I had checked CI results for So... Cross comparison between different CI runs is meaningless. I shall run benchmarks locally instead to gather data. |
|
Here's the benchmark result: With the optimization: Without optimization: The changes are within the error margin, so it seems this was a case of premature optimization. I suggest we discard this change to avoid unnecessary complexity in the codebase. |
|
It's possible that the change still works but it requires significantly larger classpath than what you tested. |
You are right, it is too early to say that the optimization is pre-mature (albeit I should have done more due diligence before opening the PR). I just posted a comment under #593 requesting for extra detail. Hopefully we can get & replicate the exact setup retronym used when they raised the issue. Once there's evidence suggesting the optimization is worthwhile, we can revisit the PR. |
|
Need to revisit this PR. When I did this PR, I noticed no improvement as this PR did not actually address the real hotspot. zinc/zinc/src/main/scala/sbt/internal/inc/LookupImpl.scala Lines 26 to 32 in 44ae3fc I didn't really understand #593 (comment) back then but now it makes a lot more sense. If build tool pass in a naive implementation of Need to look at which Update: All of I wonder if we can add a |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
LookupImpl.LookupAnalysistakesO(classpath length)to run. In project with long classpath,LookupImpl.LookupAnalysisis noticeable in profiling. (According to #593)This PR introduces a
binaryClassNameToAnalysislookup table to reduce lookup time complexity.For memory consumption of
binaryClassNameToAnalysis, assuming there are 10000 binary class names in the worst case, each with 50 characters (100 bytes), the total key size is 10000 * 100 bytes = 1 MB, which is small.Closes #593.