std: Avoid ptr::copy if unnecessary in vec::Drain

[alexcrichton]

This commit is spawned out of a performance regression investigation in #50496.
In tracking down this regression it turned out that the expand_statements
function in the compiler was taking quite a long time. Further investigation
showed two key properties:

• The function was "fast" on glibc 2.24 and slow on glibc 2.23
• The hottest function was memmove from glibc

Combined together it looked like glibc gained an optimization to the memmove
function in 2.24. Ideally we don't want to rely on this optimization, so I
wanted to dig further to see what was happening.

The hottest part of expand_statements was Drop for Drain in the call to
splice where we insert new statements into the original vector. This should
be a cheap operation because we're draining and replacing iterators of the exact
same length, but under the hood memmove was being called a lot, causing a
slowdown on glibc 2.23.

It turns out that at least one of the optimizations in glibc 2.24 was that
memmove where the src/dst are equal becomes much faster. This program
executes in ~2.5s against glibc 2.23 and ~0.3s against glibc 2.24, exhibiting
how glibc 2.24 is optimizing memmove if the src/dst are equal.

And all that brings us to what this commit itself is doing. The change here is
purely to Drop for Drain to avoid the call to ptr::copy if the region being
copied doesn't actually need to be copied. For normal usage of just Drain
itself this check isn't really necessary, but because Splice internally
contains Drain this provides a nice speed boost on glibc 2.23. Overall this
should fix the regression seen in #50496 on glibc 2.23 and also fix the
regression on Windows where memmove looks to not have this optimization.

Note that the way splice was called in expand_statements would cause a
quadratic number of elements to be copied via memmove which is likely why the
tuple-stress benchmark showed such a severe regression.

Closes#50496

[rust-highfive]

r? @aidanhs

(rust_highfive has picked a reviewer for you, use r? to override)

[kennytm]

@bors try

@Mark-Simulacrum could we do a perf check?

[bors]

⌛ Trying commit 254b601 with merge 1aac55d...

[kennytm]

Also beta-nominating this for 1.27.

[Mark-Simulacrum]

Perf has been queued.

[sfackler]

This seems like a reasonable thing to do even if it doesn't fix the perf regression. r=me

[bors]

☀️ Test successful - status-travis
State: approved= try=True

[alexcrichton]

FWIW locally on my computer (glibc 2.23)

$ time rustc +stable main.rs
rustc +stable main.rs 4.94s user 0.18s system 100% cpu 5.080 total
$ time rustc +beta main.rs
rustc +beta main.rs 5.00s user 0.09s system 98% cpu 5.185 total
$ time rustc +nightly main.rs
^C
rustc +nightly main.rs 206.66s user 0.14s system 99% cpu 3:27.45 total
$ time rustc +1aac55d18084910bbfa1d25733a5393860616b8b main.rs
rustc +1aac55d18084910bbfa1d25733a5393860616b8b main.rs 4.06s user 0.05s system 100% cpu 4.092 total

[alexcrichton]

future perf results link

[alexcrichton]

While the link I pasted above doesn't work yet this is the results comparing to the previous commit on master so either this PR or the rollup before it caused the speed boost, but I'm gonna optimistically say it was this PR :)

@bors: r=sfackler

[bors]

📌 Commit 254b601 has been approved by sfackler

[alexcrichton]

@bors: rollup