Comments (9)
The documentation on this could probably be improved, but the capacity that the BufMut
trait talks about is for cases where the buffer cannot be resized at all. Types such as Vec<u8>
pretend that they have infinite capacity in the BufMut
trait.
I agree that the wording here is confusing, but I think it is the right behavior.
from bytes.
Is there some API which basically forces me to make reallocations explicit? I would be happy to see if I can improve the documentation a little bit when I have understood it better.
from bytes.
I don't think we provide that, no.
from bytes.
Hmm, OK - thank you.
I was using a BytesMut
to store data received from the network, split it off and freeze it to send a Bytes
over to another thread for compression and logging. I tested it first and it seemed to work, probably because there were always times when all Bytes
handles had been dropped - but in the real project, I get lots of very small data packages which probably means there are always some Bytes
handles alive.
One idea to deal with this was to have two BytesMut
buffers, when one would get full I could switch to the other buffer while the remaining Bytes
from the first buffer get dropped. Then I could move back to the first buffer once there is nothing pointing to it anymore, and vice versa. Unfortunately, there doesn't seem to be an API available to check whether a BytesMut
has any live Bytes
pointing into its storage. Would you be open to adding such an API, or is my usecase already achievable some other way?
from bytes.
An API for getting the refcount is reasonable enough.
from bytes.
I gave it some thought and for my usecase, an API like #686 seems more usable - it doesn't expose implementation details like refcount, and it gives a cheap way to re-use the original implementation. Do you think that approach is sensible? If so I'd be happy to bring it to the finish line. Thanks!
from bytes.
I've thought about this too. Thanks for posting @shahn! In fact, the reason I first looked into the source code for this crate was because I didn't understand the conditions that cause allocation after reading the documentation. The following snippet from the docs is accurate, but it's not a complete picture of the BytesMut
allocation strategy and the constraints it assumes.
BytesMut’s BufMut implementation will implicitly grow its buffer as necessary. However, explicitly reserving the required space up-front before a series of inserts will be more efficient.
In particular, it's not clear that a BytesMut
instance is most efficient when the Bytes
instances it produces are short lived and, critically, all dropped before the entire buffer is filled, allowing the buffer to be reclaimed and filled again (please let me know if I've missed somewhere that's documented). It does not act as a ring buffer, filling in the empty space at the beginning of the buffer while a Bytes
is still referencing the end of the buffer.
This is a subtle distinction, but it's important to understand when choosing to use BytesMut
because if your data is received continuously and your Bytes
instances are not dropped before more data arrives then the buffer is never reclaimed and a new one is allocated every time it's filled. To be clear, I think this is the correct behavior for BytesMut
because it's making a specific trade off (i.e. less memory usage and bookkeeping in exchange for allocation when data is received continuously). It just wasn't clear to me when reading documentation.
from bytes.
I think what you explained about the behaviour is also what I've learned from docs/reading code, hence the idea to use two BytesMut
s and alternate between them.
One thing that confused me initially was that some old docs which are however still readily found using web search explicitly say that BytesMut doesn't implicitly grow its buffer - but that went away once I looked at the right docs.
I noticed large memory usage from the OS pov, perhaps there is some fragmentation issue going on with frequent allocations of different sizes, really not sure. It could be fragmentation because the messages I receive have vastly different size. This seems to be better when switching between two buffers using the patch from #686.
from bytes.
Closing with #686.
from bytes.
Related Issues (20)
- Feature Request: Default implementations for pinned types HOT 2
- Feature Request: Seekable Buffer ("SeekBuf") and cursor/iterator support HOT 2
- `BufMut` does not include safety invariants in trait documentation HOT 1
- Enable shrinking of allocations
- Confusing documentation around `Arc<[u8]>` compatibility HOT 1
- Should clone benchmark use use `test::blackbox`? HOT 1
- Explicitly guarantee `Bytes` to be immutable HOT 2
- Expose UTF-8 validated string type HOT 2
- Buf::chunks_vectored() is wrong if chunk() isn't the whole buf HOT 3
- Feature request: fallible version of `BytesMut::unsplit` (i.e. make `BytesMut::try_unsplit` public) HOT 2
- Test for unknown --cfg flags in ci
- Splice for BytesMut HOT 2
- Consider replacing Bytes::make_mut by impl From<Bytes> for BytesMut HOT 5
- Is the conversion from bytes to Vec<u8> O(1) HOT 5
- Feature request: implement `From<Cow<'static, [u8]>>` for `Bytes`
- BytesMut::zeroed doc header improvement HOT 3
- Docs: `Buf::chunk` should have more restrictions. HOT 2
- 1.6.0 yanked? HOT 12
- `impl FromIterator for BytesMut` exposes implementation details HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bytes.