Add advance on Bytes and BytesMut
#166
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In order to avoid unnecessary allocations, a `Bytes` structure remembers the capacity with which it was first created. When a reserve operation is issued, this original capacity value is used to as a baseline for reallocating new storage. Previously, this original capacity value was stored in its raw form. In other words, the original capacity `usize` was stored as is. In order to reclaim some `Bytes` internal storage space for additional features, this original capacity value is compressed from requiring 16 bits to 3. To do this, instead of storing the exact original capacity. The original capacity is rounded down to the nearest power of two. If the original capacity is less than 1024, then it is rounded down to zero. This roughly means that the original capacity is now stored as a table: 0 => 0 1 => 1k 2 => 2k 3 => 4k 4 => 8k 5 => 16k 6 => 32k 7 => 64k For the purposes that the original capacity feature was introduced, this is sufficient granularity.
This is the `advance` function that would be part of a `Buf` implementation. However, `Bytes` and `BytesMut` cannot impl `Buf` until the next breaking release. The implementation uses the additional storage made available by the previous commit to store the number of bytes that the view was advanced. The `ptr` pointer will point to the start of the window, avoiding any pointer arithmetic when dereferencing the `Bytes` handle.
carllerche
changed the title
advance on Bytes and BytesMut
|
Sorry I'm pretty out of touch with the implemenation here, you'll likely wish to find a different reviewer |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to avoid unnecessary allocations, a
Bytesstructure remembersthe capacity with which it was first created. When a reserve operation
is issued, this original capacity value is used to as a baseline for
reallocating new storage.
Previously, this original capacity value was stored in its raw form. In
other words, the original capacity
usizewas stored as is. In order toreclaim some
Bytesinternal storage space for implementingadvance,this original capacity value is compressed from requiring 16 bits to 3.
To do this, instead of storing the exact original capacity. The original
capacity is rounded down to the nearest power of two. If the original
capacity is less than 1024, then it is rounded down to zero. This
roughly means that the original capacity is now stored as a table:
For the purposes that the original capacity feature was introduced, this
is sufficient granularity.
The second commit implements
advanceby using this new storage capacityto store the window offset into the vec. The
ptr,len, andcapfieldsrepresent the active window, i.e. the user view after a call to
advance. Thismakes common operations like dereferencing the slice fast.
Relates to #74