-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Revert libbacktrace -> gimli #74613
Revert libbacktrace -> gimli #74613
Conversation
When re-landing this we should be sure to include #74591. |
@bors r+ |
📌 Commit aafe6e1df0964d50fee91d6f3a333f7de147ce8f has been approved by |
@bors rollup=never Due to perf effects. |
☔ The latest upstream changes (presumably #74578) made this pull request unmergeable. Please resolve the merge conflicts. |
aafe6e1
to
b747a33
Compare
@bors r=nnethercote |
📌 Commit b747a33 has been approved by |
☀️ Test successful - checks-actions, checks-azure |
This improved perf as expected. |
… r=Mark-Simulacrum std: Switch from libbacktrace to gimli (take 2) This is the second attempt to land rust-lang#73441 after being reverted in rust-lang#74613. Will be gathering precise perf numbers here in this take. Closes rust-lang#71060
This reverts 4cbd265 028f8d7 13db3cc d7a36d8 (and technically 79673d3 but it's made empty by previous reverts).
The current plan is to land this PR as a temporary change, so that we can get a better handle on the regressions introduced by it. Trying to fix/examine them in master is difficult, and we want to be better able to evaluate them without impact to other PRs being landed in the mean time.
That said, it is currently my belief that gimli, in one form or another, will need to land sometime soon. I think it's quite likely that it may slip a week or two, but I would personally push for re-landing it then "regardless" of the regressions. We should try to focus efforts on understanding and removing as much of the performance impact as possible, as everyone pretty much agrees that it should be quite minimal (and entirely in the linker, basically).
r? @nnethercote