Vec<u8> clone in rustc 1.33.0 is 3 times slower than rustc 1.29.0

[breezewish]

Benchmark code:

#[bench]
fn bench(b: &mut test::Bencher) {
    let raw = vec![0u8; 1000];
    b.iter(|| {
        test::black_box(test::black_box(&raw).clone());
    });
}

In rustc 1.29.0-nightly (4f3c7a4 2018-07-17): 32 ns/iter (+/- 34)
In rustc 1.33.0-nightly (9eac386 2018-12-31): 127 ns/iter (+/- 45)

[killercup]

Can you try this? #47745 (comment)

[breezewish]

@killercup

Hi, I tried with the following profile:

[profile.bench]
lto = false
opt-level = 3
debug = true
codegen-units = 1

[profile.release]
lto = false
opt-level = 3
debug = true
codegen-units = 1

and

[profile.bench]
lto = true
opt-level = 3
debug = true
codegen-units = 1

[profile.release]
lto = true
opt-level = 3
debug = true
codegen-units = 1

the outcome is similar.

[ollie27]

I'd guess this is due to #55238. You could try using jemallocator to confirm.

[brson]

@ollie27 Oh very good guess. That would explain a lot. I do think that @breeswish's benchmarks are running against system malloc in the 'after' run. We are running at least one set of benchmarks with jemalloc both before/after: https://gist.github.com/brson/13586d9f12f3af5c8377628c3d0f12d0#file-benchcmp-tikv and have seen regressions there too, but not investigated.

We'll fix our side to make sure we are comparing jemalloc to jemalloc then see how our benchmarks look.

[brson]

What I reported yesterday about not comparing allocator to allocator looks to be incorrect. @breeswish's benchmarks may have been using the same jemalloc. Still investigating.

[mati865]

What is your system?

Since switch system allocator I'm seeing small performance increase on 3 systems with glibc 2.28 (Arch Linux, Fedora and Ubuntu).

With your benchmark I was getting results so close they weren't reliable.
These are results with let raw = vec![0u8; 1000000];:

$ cargo +nightly-2018-07-17 bench
[...]
test bench ... bench:      19,454 ns/iter (+/- 241)

$ cargo +nightly-2018-07-17 bench
[...]
test bench ... bench:      19,422 ns/iter (+/- 207)

$ cargo +nightly-2018-12-31 bench
[...]
test bench ... bench:      19,378 ns/iter (+/- 2,560)

$ cargo +nightly-2018-12-31 bench
[...]
test bench ... bench:      19,374 ns/iter (+/- 422)

$ cargo +nightly bench           
[...]
test bench ... bench:      19,352 ns/iter (+/- 7,552)

$ cargo +nightly bench
[...]
test bench ... bench:      19,342 ns/iter (+/- 7,586)

[breezewish]

Hi @mati865 My OS is MacOS 10.12.6. I will try again with jemalloc linked. During that, you may first view a result powered by Travis CI (although it may not be very stable, but still referable): https://travis-ci.com/breeswish/vec_clone_play

[mati865]

@breeswish I don't use macOS so I cannot speak for it but for such old Linux distributions jemallocator should fix the performance.

[brson]

After further investigation, there indeed wasn't a problem with Vec<u8>, so this can be closed.

[breezewish]

I forced to use jemalloc and discovered that there is no notable difference in the case reported by this issue. So closing.