Remove Box from RcSlice

[Mark-Simulacrum]

This isn't necessary as Rc/Arc already have an internal heap allocation,
so the additional Box represented a useless pointer dereference.

[rust-highfive]

r? @petrochenkov

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

[Mark-Simulacrum]

cc @nnethercote

[nnethercote]

Nice! I actually looked at this myself because these allocations were showing up as moderately hot in some profiles, but I managed to convince myself they were unavoidable O_o

[Mark-Simulacrum]

r? @eddyb

[eddyb]

Note that there is a cost here of moving the contents into an Rc.
r=me if that's accounted for and this is a net positive.

[Mark-Simulacrum]

@bors try

[bors]

⌛ Trying commit 79010c2 with merge d9589e4...

[bors]

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

[Mark-Simulacrum]

@nnethercote This does seem to be a regression in wall time and memory usage.. https://perf.rust-lang.org/compare.html?start=685faa2c3ee062aaf30ddf6d3daf4ef3b576979b&end=d9589e4c2db96769a2be22f29625cb31266557cc&stat=max-rss. I guess maybe we shouldn't land this? Is your interpretation different?

[nnethercote]

I took a look at deep-vector and regex with Cachegrind and DHAT. deep-vector because it showed the big regression, and regex because DHAT shows its the benchmark that has the highest proportion of these RcSlice allocations.

DHAT agrees that the max RSS does increase significantly for deep-vector. (I get a 16% increase on a clean-check build.) Presumably because we end up having two copies of the data live while copying from the Vector to the slice.

Other than that, there's not much change -- regex is hardly affected -- and no clear benefit. The total number of allocations done doesn't change. Instruction counts don't change.

It's a shame, but I agree that this shouldn't be landed.

[Mark-Simulacrum]

Thanks for verifying!