[DO NOT MERGE] Test the hashbrown add-is_empty-checks branch.#92239
[DO NOT MERGE] Test the hashbrown add-is_empty-checks branch.#92239nnethercote wants to merge 3 commits intorust-lang:masterfrom
add-is_empty-checks branch.#92239Conversation
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +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 |
|
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. |
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