[DO NOT MERGE] Test the hashbrown add-is_empty-checks branch.
#92239
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
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit d347ea9 with merge a73ccfae448712957ea5d06f7fdc808c2c0d8f87... |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
The bot guessed wrongly. Here is the real error: I don't understand what's going wrong. |
|
I think you might have more luck adding your version of hashbrown to the |
Yeah, dist is building rust-src package which vendors all the dependencies and if you have inconsistent ones across several crates it fails.
That may not be sufficient if rust-analyzer pulls in its own hashbrown and causes a vendoring conflict. I ran into the same problem in #90673 so You can check locally with tidy and |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
With only mingw-check failing, it should be possible get a CI perf run happening, as in #92548... @bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
|
⌛ Trying commit 0a7dbb6 with merge 691321f2a47ccc68389c3c5cce2ab0873b94c702... |
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
💔 Test failed - checks-actions |
bors
added
the
S-waiting-on-author
|
I'm not sure which use-cases of try artifacts would be broken by this but here goes: you could remove the cargo vendor step making (In fact I can probably test that theory for you before your TZ rolls over a new day. Update: dist succeeded in the #92585 try build) |
|
rust-lang/hashbrown#305 now has a pull request, so this PR isn't needed any more. |
|
Thanks, @lqd! The results ended up here. They are curious. On local measurements I got uniform instruction count wins, with no regressions. On CI there were a lot of instruction count wins, but also some regressions. But the cycle time results -- which are a more realistic metric than instruction counts, but normally are noisy -- are great! Almost universal improvements, up to 4.65%, plus one 11% which I don't trust. The wall-time results also look decent. They're so noisy that you have to show the non-significant results to see many results, but there are clearly more wins than losses, which suggests a real improvement overall. Based on this, I will submit a PR to hashbrown. |
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.
This gave lots of small instruction count wins (up to 1.3%) during local measurements. This PR is to measure the change on CI. It refers to a branch on my fork of
hashbrownand so isn't suitable for landing.r? @ghost