]> git.lizzy.rs Git - rust.git/commit - src/tools/rustfmt
Auto merge of #78317 - est31:linear_in_impl_count, r=matthewjasper
authorbors <bors@rust-lang.org>
Sun, 20 Dec 2020 19:54:15 +0000 (19:54 +0000)
committerbors <bors@rust-lang.org>
Sun, 20 Dec 2020 19:54:15 +0000 (19:54 +0000)
commitc609b2eaf323186a1167ec1a9ffa69a7d4a5b1b9
treecfe92040fc57b5e8bb2b08d37dbf49e9eafbf0f7
parentb0e5c7d1fee37f1890455b977495bfe262716701
parent73a7d935dc55b4757706a966179459670e386582
Auto merge of #78317 - est31:linear_in_impl_count, r=matthewjasper

Turn quadratic time on number of impl blocks into linear time

Previously, if you had a lot of inherent impl blocks on a type like:

```Rust
struct Foo;

impl Foo { fn foo_1() {} }
// ...
impl Foo { fn foo_100_000() {} }
```

The compiler would be very slow at processing it, because
an internal algorithm would run in O(n^2), where n is the number
of impl blocks. Now, we add a new algorithm that allocates but
is faster asymptotically.

Comparing rustc nightly with a local build of rustc as of this PR (results in seconds):

| N | real time before | real time after |
| - | - | - |
| 4_000 | 0.57 | 0.46 |
| 8_000  | 1.31  | 0.84 |
| 16_000  | 3.56 | 1.69 |
| 32_000 | 10.60 | 3.73 |

I've tuned up the numbers to make the effect larger than the startup noise of rustc, but the asymptotic difference should hold for smaller n as well.

Note: current state of the PR omits error messages if there are other errors present already. For now, I'm mainly interested in a perf run to study whether this issue is present at all. Please queue one for this PR. Thanks!