-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
read_to_end grows buf beyond take limit #5594
Comments
Thank you. This does indeed seem like a bug. |
I would like to tackle this, but I don't know how or if it is even desirable. If you used |
It will be somewhat of an optimization. Here's what I suggest: if the vector is exactly filled, then we can try to read into an This should handle the case where the vector has exactly the right capacity without reallocating. For cases where the capacity isn't sufficient, we make one small read, but it's probably fine since we only make one. |
Naively I would’ve been tempted to use the information passed in to As for |
It would be possible to special-case |
Version
1.25.0
Platform
Description
When calling
read_to_end
on anAsyncRead
with atake(n)
limit and a bufVec<u8>
initializedwith_capacity(n)
, the buf is unnecessarily grown beyondn
, incurring an expensiverealloc
.The code above yields the following info output:
The buf has been doubled in size despite only containing the number of bytes that was specified in
take(n)
and being initializedwith_capacity(n)
.I would expect the
take(n)
to prevent the buf from being grown beyondn
.It seems to me that this is due to the unconditional call to
buf.reserve(32)
inpoll_read_to_end
.The text was updated successfully, but these errors were encountered: