-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Simplify lazy DefPathHash decoding by using an on-disk hash table. #82183
Simplify lazy DefPathHash decoding by using an on-disk hash table. #82183
Conversation
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 3d71523c6e45ae4e9c99bd32f8625bab2bd600de with merge 6da745eb8d19cfce6764aac7f880ad7503397d14... |
☀️ Try build successful - checks-actions |
Queued 6da745eb8d19cfce6764aac7f880ad7503397d14 with parent f1c47c7, future comparison URL. |
Finished benchmarking try commit (6da745eb8d19cfce6764aac7f880ad7503397d14): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
OK, those results look promising. There's still a couple more variations to try. |
Let's see if we can remove the global @bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 975c6c821e71b3186b8d51455e3090014a19183d with merge 2a538c388dc56268456c9ff721a719cc9f630dda... |
☀️ Try build successful - checks-actions |
Queued 2a538c388dc56268456c9ff721a719cc9f630dda with parent ee88f46, future comparison URL. |
Finished benchmarking try commit (2a538c388dc56268456c9ff721a719cc9f630dda): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
It looks like performance is almost the same without the additional caching layer (0.1% - 0.3% difference). Let's see if we can get rid of the regressions in non-incremental builds. |
8ec80dc
to
4ca1a53
Compare
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 4ca1a5359e9bd9b9b15ff031e13414e3ad4c092b with merge 649c77c9429915099bc407a418baad103403a54f... |
☀️ Try build successful - checks-actions |
Queued 649c77c9429915099bc407a418baad103403a54f with parent 25a2c13, future comparison URL. |
Finished benchmarking try commit (649c77c9429915099bc407a418baad103403a54f): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
Let's give it another try with the fixed version of odht. @bors r=wesleywiser |
📌 Commit 4d151d9 has been approved by |
⌛ Testing commit 4d151d9 with merge 5cccabccb9d354c6fb4fa78e0bb36faf9e8d7513... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
Seems unrelated? @bors retry |
☀️ Test successful - checks-actions |
Finished benchmarking commit (d6cd2c6): comparison url. Summary: This change led to very large relevant mixed results 🤷 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression |
Visiting for weekly performance triage: the wins here massively outweigh the few slight losses. @rustbot label: +perf-regression-triaged |
local_def_path_hash_to_def_id is used by Debug impl for DepNode and it looks for DefPathHash inside the current compilation. During incremental compilation we are going through nodes that belong to a previous compilation and might not be present and a simple attempt to print such node with tracing::debug (try_mark_parent_green does it for example) results in a otherwise avoidable panic Panic was added in rust-lang#82183, specifically in 2b60338, with a comment "We only use this mapping for cases where we know that it must succeed.", but I'm not sure if this property holds when we traverse nodes from the old compilation in order to figure out if they are valid or not
local_def_path_hash_to_def_id is used by Debug impl for DepNode and it looks for DefPathHash inside the current compilation. During incremental compilation we are going through nodes that belong to a previous compilation and might not be present and a simple attempt to print such node with tracing::debug (try_mark_parent_green does it for example) results in a otherwise avoidable panic Panic was added in rust-lang#82183, specifically in 2b60338, with a comment "We only use this mapping for cases where we know that it must succeed.", but I'm not sure if this property holds when we traverse nodes from the old compilation in order to figure out if they are valid or not
local_def_path_hash_to_def_id is used by Debug impl for DepNode and it looks for DefPathHash inside the current compilation. During incremental compilation we are going through nodes that belong to a previous compilation and might not be present and a simple attempt to print such node with tracing::debug (try_mark_parent_green does it for example) results in a otherwise avoidable panic Panic was added in rust-lang#82183, specifically in 2b60338, with a comment "We only use this mapping for cases where we know that it must succeed.", but I'm not sure if this property holds when we traverse nodes from the old compilation in order to figure out if they are valid or not
This PR simplifies the logic around mapping
DefPathHash
values encountered during incremental compilation to validDefId
s in the current session. It is able to do so by using an on-disk hash table encoding that allows for looking up values directly, i.e. without deserializing the entire table.The main simplification comes from not having to keep track of
DefPathHashes
being used during the compilation session.