-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
io: clearly document when CopyBuffer does not use the buffer #32306
Comments
CopyBuffer is meant to be used when profiling shows it would be helpful. I don't see any point to deprecating it in favor of more complex code using the much more general bufio. |
Perhaps the right fix here is to move the explicit tests for |
@bcmills Any thoughts on #32306 (comment)? |
I don't think that changing the behavior of In particular, changing |
Our decision is that we aren't going to remove -- for @golang/proposal-review |
Thank you @bcmills for this issue and @rsc and @ianlancetaylor for the discussion and direction! @bcmills given the direction of this issue, this issue boils down to just documenting that if src implements io.ReaderFrom and dst implements io.WriterTo, then buf won't be used, and that then means that this issue is a duplicate of #32276 for which there is already a CL that I am going to review shortly. I shall therefore close this issue as a duplicate. Please feel free to reopen though. |
io.CopyBuffer
is difficult to use appropriately: it has a subtle interaction withReadFrom
andWriteTo
methods (#16474, #32276) that can result in unintended use of small buffers and/or unintended allocation of large slices.For the cases that avoid that subtle interaction,
io.CopyBuffer
mostly duplicates the functionality ofbufio.Reader
, particularly given the(*bufio.Reader).Reset
method (which allows a singlebufio.Reader
to wrap multipleio.Reader
instances).I propose that we deprecate
io.CopyBuffer
, and encourage explicit use ofbufio.Reader
as a replacement.In particular, note that if the caller intends to always use the buffer, call sites of the form:
can be expressed more clearly (and more robustly) as
The two cases I've found where the existing behavior of
io.CopyBuffer
is always beneficial are:src
argument is a*bytes.Reader
(or similario.WriterTo
with an internal[]byte
containing its complete output), orsrc
argument is a*strings.Reader
(or similario.WriterTo
with an internalstring
containing the complete output) and thedst
argument implementsio.StringWriter
.In those cases,
io.CopyBuffer
avoids an extra copy without inducing an extra allocation. However, as noted in #16474 (comment), detecting those cases requires much more detailed information than whatio.CopyBuffer
currently uses (and whatReaderFrom
andWriterTo
currently provide).Moreover, if the caller knows that the
WriterTo
method, if any, is likely to be more efficient than buffering, it's easy enough to invoke explicitly, with explicit use of buffering on the fallback path:The text was updated successfully, but these errors were encountered: