Speed up item_bodies for large match statements involving regions#57494
Merged
bors merged 2 commits intorust-lang:masterfrom Jan 13, 2019
Merged
Speed up item_bodies for large match statements involving regions#57494bors merged 2 commits intorust-lang:masterfrom
bors merged 2 commits intorust-lang:masterfrom
Conversation
Once a region has been expanded to cover a fixed region, a corresponding RegSubVar constraint won't have any effect on the expansion anymore, the same is true for constraints where the variable on the RHS has already reached static scope. By removing those constraints from the set that we're iterating over, we remove a lot of needless overhead in case of slow convergences (i.e. lots of iterations). For the unicode_normalization crate, this about cuts the time required for item_bodies checking in half.
This comment has been minimized.
This comment has been minimized.
In functions with lots of region constraint, if the fixed point iteration converges only slowly, a lot of the var/var constraints will have equal regions most of the time. Yet, we still perform the LUB calculation and try to intern the result. Especially the latter incurs quite some overhead. This reduces the take taken by the item bodies checking pass for the unicode_normalization crate by about 75%.
Contributor
Author
|
Removed the commit that modifies the match checking code for now, as that caused a test failure. |
Contributor
|
@bors try |
Collaborator
|
@lzutao: 🔑 Insufficient privileges: not in try users |
Member
|
@bors try |
Collaborator
bors
added a commit
that referenced
this pull request
Jan 10, 2019
Speed up item_bodies for large match statements involving regions These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead. The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though). Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them. Ref #55528 cc unicode-rs/unicode-normalization#29 r? @nikomatsakis
Collaborator
|
☀️ Test successful - checks-travis |
Contributor
|
@rust-timer build 960c730 |
Collaborator
|
Insufficient permissions to issue commands to rust-timer. |
Contributor
Author
|
@rust-timer build 960c730 |
Collaborator
|
Insufficient permissions to issue commands to rust-timer. |
Member
|
@rust-timer build 960c730 |
Collaborator
|
Success: Queued 960c730 with parent 6ecad33, comparison URL. |
Collaborator
|
Finished benchmarking try commit 960c730 |
nikomatsakis
approved these changes
Jan 11, 2019
Contributor
|
@bors r+ |
Collaborator
|
📌 Commit 5f402b8 has been approved by |
emilyalbini
added a commit
to emilyalbini/rust
that referenced
this pull request
Jan 12, 2019
Speed up item_bodies for large match statements involving regions These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead. The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though). Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them. Ref rust-lang#55528 cc unicode-rs/unicode-normalization#29 r? @nikomatsakis
Centril
added a commit
to Centril/rust
that referenced
this pull request
Jan 13, 2019
Speed up item_bodies for large match statements involving regions These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead. The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though). Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them. Ref rust-lang#55528 cc unicode-rs/unicode-normalization#29 r? @nikomatsakis
bors
added a commit
that referenced
this pull request
Jan 13, 2019
Rollup of 16 pull requests Successful merges: - #57351 (Don't actually create a full MIR stack frame when not needed) - #57353 (Optimise floating point `is_finite` (2x) and `is_infinite` (1.6x).) - #57412 (Improve the wording) - #57436 (save-analysis: use a fallback when access levels couldn't be computed) - #57453 (lldb_batchmode.py: try `import _thread` for Python 3) - #57454 (Some cleanups for core::fmt) - #57461 (Change `String` to `&'static str` in `ParseResult::Failure`.) - #57473 (std: Render large exit codes as hex on Windows) - #57474 (save-analysis: Get path def from parent in case there's no def for the path itself.) - #57494 (Speed up item_bodies for large match statements involving regions) - #57496 (re-do docs for core::cmp) - #57508 (rustdoc: Allow inlining of reexported crates and crate items) - #57547 (Use `ptr::eq` where applicable) - #57557 (resolve: Mark extern crate items as used in more cases) - #57560 (hygiene: Do not treat `Self` ctor as a local variable) - #57564 (Update the const fn tracking issue to the new metabug) Failed merges: r? @ghost
This file contains hidden or 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
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.
These changes don't change anything about the complexity of the algorithms, but use some easy shortcuts or modifications to cut down some overhead.
The first change, which incrementally removes the constraints from the set we're iterating over probably introduces some overhead for small to medium sized constraint sets, but it's not big enough for me to observe it in any project I tested against (not that many though).
Though most other crates probably won't improve much at all, because huge matches aren't that common, the changes seemed simple enough for me to make them.
Ref #55528
cc unicode-rs/unicode-normalization#29
r? @nikomatsakis