-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Make Decodable
and Decoder
infallible.
#93066
Conversation
Some changes occured to the CTFE / Miri engine cc @rust-lang/miri |
@bors try @rust-timer queue |
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
⌛ Trying commit 197488707c3679e8418fefc5555d3b90f821b59d with merge 88a40e21d3ce57d409eeb40ec75bb9aff99e7836... |
☀️ Try build successful - checks-actions |
Queued 88a40e21d3ce57d409eeb40ec75bb9aff99e7836 with parent e5e2b0b, future comparison URL. |
Finished benchmarking commit (88a40e21d3ce57d409eeb40ec75bb9aff99e7836): comparison url. Summary: This change led to large relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. While you can manually mark this PR as fit for rollup, we strongly recommend not doing so since this PR led to changes in compiler perf. @bors rollup=never |
Perf results are good, but not as good as I got locally. Instruction counts:
My hypothesis for these differences is still PGO. Particularly for this sort of change which involves many small changes spread out over a lot of code. |
I have updated the code for the requested changes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
r=me with typos fixed
9a52d4c
to
785f043
Compare
@bors r=bjorn3 |
📌 Commit 785f0435c21e8a8de83e948d66df76b62e7fa285 has been approved by |
☔ The latest upstream changes (presumably #93138) made this pull request unmergeable. Please resolve the merge conflicts. |
Because `()` is called "unit" and it makes it match `Encoder::emit_unit`.
`Decoder` has two impls: - opaque: this impl is already partly infallible, i.e. in some places it currently panics on failure (e.g. if the input is too short, or on a bad `Result` discriminant), and in some places it returns an error (e.g. on a bad `Option` discriminant). The number of places where either happens is surprisingly small, just because the binary representation has very little redundancy and a lot of input reading can occur even on malformed data. - json: this impl is fully fallible, but it's only used (a) for the `.rlink` file production, and there's a `FIXME` comment suggesting it should change to a binary format, and (b) in a few tests in non-fundamental ways. Indeed rust-lang#85993 is open to remove it entirely. And the top-level places in the compiler that call into decoding just abort on error anyway. So the fallibility is providing little value, and getting rid of it leads to some non-trivial performance improvements. Much of this commit is pretty boring and mechanical. Some notes about a few interesting parts: - The commit removes `Decoder::{Error,error}`. - `InternIteratorElement::intern_with`: the impl for `T` now has the same optimization for small counts that the impl for `Result<T, E>` has, because it's now much hotter. - Decodable impls for SmallVec, LinkedList, VecDeque now all use `collect`, which is nice; the one for `Vec` uses unsafe code, because that gave better perf on some benchmarks.
785f043
to
37fbd91
Compare
I rebased to fix the conflicts. @bors r=bjorn3 |
📌 Commit 37fbd91 has been approved by |
☀️ Test successful - checks-actions |
Finished benchmarking commit (84322ef): comparison url. Summary: This change led to large relevant improvements 🎉 in compiler performance.
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. @rustbot label: -perf-regression |
Make `Encodable` and `Encoder` infallible. A follow-up to rust-lang#93066. r? `@ghost`
Decoder
has two impls:currently panics on failure (e.g. if the input is too short, or on a
bad
Result
discriminant), and in some places it returns an error(e.g. on a bad
Option
discriminant). The number of places whereeither happens is surprisingly small, just because the binary
representation has very little redundancy and a lot of input reading
can occur even on malformed data.
.rlink
file production, and there's aFIXME
comment suggesting itshould change to a binary format, and (b) in a few tests in
non-fundamental ways. Indeed Remove all json handling from rustc_serialize #85993 is open to remove it entirely.
And the top-level places in the compiler that call into decoding just
abort on error anyway. So the fallibility is providing little value, and
getting rid of it leads to some non-trivial performance improvements.
Much of this PR is pretty boring and mechanical. Some notes about
a few interesting parts:
Decoder::{Error,error}
.InternIteratorElement::intern_with
: the impl forT
now has the sameoptimization for small counts that the impl for
Result<T, E>
has,because it's now much hotter.
collect
, which is nice; the one forVec
uses unsafe code, becausethat gave better perf on some benchmarks.
r? @bjorn3