Add fast path for match checking

[ishitatsuyuki]

This adds a fast path that would reduce the complexity to linear on matches consisting of only variant patterns (i.e. enum matches). (Also see: #7462) Unfortunately, I was too lazy to add a similar fast path for constants (mostly for integer matches), ideally that could be added another day.

TBH, I'm not confident with the performance claims due to the fact that enums tends to be small and FxHashMap could add a lot of overhead.

r? @Mark-Simulacrum

needs perf

[jonas-schievink]

@bors try @rust-timer queue

[rust-timer]

Awaiting bors try build completion

[bors]

⌛ Trying commit 7c98f6f with merge 52836408ae482f87159a2473c3e5475348b1f255...

[bors]

☀️ Try build successful - checks-actions, checks-azure
Build commit: 52836408ae482f87159a2473c3e5475348b1f255 (52836408ae482f87159a2473c3e5475348b1f255)

[rust-timer]

Queued 52836408ae482f87159a2473c3e5475348b1f255 with parent fd702d2, future comparison URL.

[rust-timer]

Finished benchmarking try commit (52836408ae482f87159a2473c3e5475348b1f255): comparison url.

Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying rollup- to bors.

Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up.

@bors rollup=never

[ishitatsuyuki]

Seems that all perf results are nearly identical. I guess that match checking wasn't dominating the compile time then.

It seems that this PR only helps in pathological cases like that generated by the script below. Some crate in the ecosystem might be doing the same kind of code generation, though, and this can be become useful in such cases.

Python script:

print("""#![allow(warnings)]
enum A {""")
for i in range(8192):
    print(f"    Var{i},")
print("""}
fn main() {
    match A::Var0 {""")
for i in range(8192):
    print(f"        A::Var{i} => {{}}")
print("""    }
}""")

Old rustc takes around 2.7s, this build takes around 1.7s.

[panstromek]

Btw. Addressing your concerns about FxHashMap overhead - #72412 added a MiniMap for similar reasons (it's SSO map backed by ArrayVec). You can try using that here, seems like the map will always hold small number of elements, too, if I understand it correctly.

[ishitatsuyuki]

It seems that MiniMap is pretty limited - it doesn't support iteration and entry. So for now I'm not going to make the switch.

[ishitatsuyuki]

I added some more comments explaining the code per request.

[oli-obk]

Thanks, that helps a lot!

One thing that we could do is to add your pathological case to the perf test suite, then, once that's in, this PR will show an improvement on the perf bot and we thus guard against future regressions.

Another thing is to debug_assert! that the result of the fast path is the same as the slow path. This will require running both paths if debug assertions are activated, but I think it could be reasonably added. What do you think?

[ishitatsuyuki]

I added the debug assertions, it has a clone that is not really necessary but I thought the code would be easier to maintain this way.

As for perf, I have mixed feelings since the case I mentioned above is only one kind of match that is slow; I think we could add it once we have support for integer cases like #7462 (comment).

[oli-obk]

You can add perf tests for both the integer case and your case within one test, then we are at least tracking them, and any changes to it will show up. If the tests just take a few seconds, that's perfect for perf, as it won't really slow down the perf test suite

[oli-obk]

Implementation wise this PR lgtm now, so we could merge it and add the perf test later if you prefer. We'd lose the visible improvement in the perf tests, but I'm not sure how much value that has.

[ishitatsuyuki]

Perf PR is up at rust-lang/rustc-perf#769.

[ishitatsuyuki]

The match-stress-enum perf benchmark is now fully deployed.

[Mark-Simulacrum]

r? @oli-obk -- it sounds like you're r+ on this, but not quite sure.

[oli-obk]

@bors r+ rollup=never

[bors]

📌 Commit 01a771a has been approved by oli-obk

[bors]

⌛ Testing commit 01a771a with merge e599b53...

[bors]

☀️ Test successful - checks-actions, checks-azure
Approved by: oli-obk
Pushing e599b53 to master...