attempt to optimise vectored write

[conradludgate]

benchmarked:

old:

test io::cursor::tests::bench_write_vec                     ... bench:          68 ns/iter (+/- 2)
test io::cursor::tests::bench_write_vec_vectored            ... bench:         913 ns/iter (+/- 31)

new:

test io::cursor::tests::bench_write_vec                     ... bench:          64 ns/iter (+/- 0)
test io::cursor::tests::bench_write_vec_vectored            ... bench:         747 ns/iter (+/- 27)

More unsafe than I wanted (and less gains) in the end, but it still does the job

[rust-highfive]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[rust-highfive]

r? @Mark-Simulacrum

(rust-highfive has picked a reviewer for you, use r? to override)

[Mark-Simulacrum]

Hm, it seems to me that I'd expect the sequence here (reserve + memset) to be pretty much exactly what resize(pos, 0) compiles to. Is that not the case today? Should we be fixing this function, and not whatever makes resize optimize poorly?

[conradludgate]

Certainly a good idea. The issue with resize is that it directly calls extend_with_slice, which always calls reserve and then does this exact assign loop.

The optimiser is very bad at optimising out allocations. But maybe there is a way here to make it slightly more effective.

[conradludgate]

I've put together this incredibly simple example: https://godbolt.org/z/bobosGa9r to demonstrate that it always double-allocs. I'm not too adept to how the lowering works, I guess somewhere it inlines late and doesn't have the correct information still lying around to determine that one of the branches is redundant

[Mark-Simulacrum]

Can you squash the commits into one? I think with that this seems OK to merge.

[Mark-Simulacrum]

@rustbot author

[conradludgate]

@rustbot ready

[Mark-Simulacrum]

@bors r+ rollup=never

[bors]

📌 Commit 803083a has been approved by Mark-Simulacrum

[bors]

⌛ Testing commit 803083a with merge 64eb9ab...

[bors]

☀️ Test successful - checks-actions
Approved by: Mark-Simulacrum
Pushing 64eb9ab to master...

[rust-timer]

Finished benchmarking commit (64eb9ab): comparison url.

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

• Primary benchmarks: no relevant changes found
• Secondary benchmarks: 🎉 relevant improvement found

	mean1	max	count2
Regressions 😿 (primary)	N/A	N/A	0
Regressions 😿 (secondary)	N/A	N/A	0
Improvements 🎉 (primary)	N/A	N/A	0
Improvements 🎉 (secondary)	-3.2%	-3.2%	1
All 😿🎉 (primary)	N/A	N/A	0

Cycles

Results

• Primary benchmarks: mixed results
• Secondary benchmarks: 😿 relevant regression found

	mean1	max	count2
Regressions 😿 (primary)	2.1%	2.1%	1
Regressions 😿 (secondary)	2.4%	2.4%	1
Improvements 🎉 (primary)	-2.3%	-2.3%	1
Improvements 🎉 (secondary)	N/A	N/A	0
All 😿🎉 (primary)	-0.1%	-2.3%	2

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression

Footnotes

1. the arithmetic mean of the percent change ↩ ↩²

2. number of relevant changes ↩ ↩²