Use is_write_vectored to optimize the write_vectored implementation for BufWriter #78768
Conversation
|
r? @cramertj (rust_highfive has picked a reviewer for you, use r? to override) |
rust-highfive
added
the
S-waiting-on-review
|
Did you see #78551? That PR is also making changes to the way BufWriter works. I didn't look at your changes yet, but judging by the PR title there's a lot of overlap. |
m-ou-se
added
the
T-libs-api
Thanks @m-ou-se, I was unaware of it! One difference I see is that it may try to flush the buffer multiple times while going over the slices. I think this is a violation of the contract of |
I was wrong, #78551 does better. It's also a more extensive change, so I will try to incorporate the part of it that applies to |
mzabaluev
force-pushed
the
optimize-buf-writer
branch
from
ce4bf64 to
dc9493d
Compare
mzabaluev
force-pushed
the
optimize-buf-writer
branch
from
caa004c to
3b6fd80
Compare
If the underlying writer does not support efficient vectored output, do it differently: always try to coalesce the slices in the buffer until one comes that does not fit entirely. Flush the buffer before the first slice if needed.
BufWriter provides an efficient implementation of write_vectored also when the underlying writer does not support vectored writes.
Now that BufWriter always claims to support vectored writes, look through it at the wrapped writer to decide whether to use vectored writes for LineWriter.
Do what write does and optimize for the most likely case: slices are much smaller than the buffer. If a slice does not fit completely in the remaining capacity of the buffer, it is left out rather than buffered partially. Special treatment is only left for oversized slices that are written directly to the underlying writer.
mzabaluev
force-pushed
the
optimize-buf-writer
branch
from
3b6fd80 to
674dd62
Compare
JohnCSimon
added
S-waiting-on-author
|
@mzabaluev - Ping from triage. Can you please post the status of this PR? |
|
@JohnCSimon It's ready for review, I believe. I have made changes that reduce branching while optimizing for the most likely case: the slices passed to |
Dylan-DPC-zz
added
S-waiting-on-review
|
@cramertj this is ready for review |
|
@bors r+ |
|
📌 Commit 674dd62 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
In case when the underlying writer does not have an efficient implementation
write_vectored, the present implementation ofwrite_vectoredforBufWritermay still forward vectored writes directly to the writer depending on the total length of the data. This misses the advantage of buffering, as the actually written slice may be small.Provide an alternative code path for the non-vectored case, where the slices passed to
BufWriterare coalesced in the buffer before being flushed to the underlying writer with plainwritecalls. The buffer is only bypassed if an individual slice's length is at least as large as the buffer.Remove a FIXME comment referring to #72919 as the issue has been closed with an explanation provided.