-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
std.RingBuffer: Implement mem.copy read/write #17400
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
Conversation
c5d1657 to
ccb0286
Compare
|
failed build due to fmt, fixed now so should build all archs |
andrewrk
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for working on this.
e4c472a to
7204b79
Compare
lib/std/RingBuffer.zig
Outdated
|
|
||
| const Allocator = @import("std").mem.Allocator; | ||
| const assert = @import("std").debug.assert; | ||
| const copy = @import("std").mem.copy; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Lines 195 to 197 in b3aaf85
| /// Deprecated: use `@memcpy` if the arguments do not overlap, or | |
| /// `copyForwards` if they do. | |
| pub const copy = copyForwards; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
modified to support both @memcpy and copyForwards via separate methods, no longer using deprecated copy
7204b79 to
a8eb70c
Compare
|
Looks good, thank you! |
This reverts a bug introduced in ziglang#17400 when decompressing a RLE block into a ring buffer.
This reverts a change introduced in ziglang#17400 causing a bug when decompressing an RLE block into a ring buffer. RLE blocks contain only a single byte of data to copy into the output, so attempting to copy a slice causes buffer overruns and incorrect decompression.
This reverts a change introduced in #17400 causing a bug when decompressing an RLE block into a ring buffer. RLE blocks contain only a single byte of data to copy into the output, so attempting to copy a slice causes buffer overruns and incorrect decompression.
This reverts a change introduced in #17400 causing a bug when decompressing an RLE block into a ring buffer. RLE blocks contain only a single byte of data to copy into the output, so attempting to copy a slice causes buffer overruns and incorrect decompression.
Metron benchmarks on M1 mac, testing time to write a slice to buffer then read it. Number corresponds to input size in bytes. RingBuffer capacity > 500.
Can see a slight loss in performance for small read/write sizes, mostly for the new read methods, however old read method still exists so not an issue. New write method is strictly an improvement. Huge improvements for large read/write sizes. Have not benchmarked writing data with a length greater than RingBuffer capacity but new writeSlice() method will be extremely efficient here as it skips data that will get overwritten (excluding first write). 23x performance for new impl with 500 bytes length write/read
Could eek out some more performance improvements by forcing capacity to a power of two to enable for bitwise AND masking but fairly negligible - not allowing for writing a slice of length > max buffer length would also improve write performance slightly due to removal of branch and one @min call
also still very easy to use buffer to write a slice byte by byte manually as with previous writeSlice implementation via manual use of write() function in loop