jorgecarleitao commented on a change in pull request #9044:
URL: https://github.com/apache/arrow/pull/9044#discussion_r550909617
##########
File path: rust/arrow/src/buffer.rs
##########
@@ -774,16 +756,16 @@ impl MutableBuffer {
/// `new_len` will be zeroed out.
///
/// If `new_len` is less than `len`, the buffer will be truncated.
- pub fn resize(&mut self, new_len: usize) {
+ pub fn resize(&mut self, new_len: usize, value: u8) {
Review comment:
I based this signature on `Vec::resize`. I.e. I am assuming here that we
use `MutableBuffer` as a special `Vec<u8>` that uses our custom allocator, and
offer users an API that they are used to (`Vec`).
The main use-case for `value: 255u8` is when we want to allocate and grow a
set bitmap to later unset bits. We did not offer that before, which is the
reason `MutableArrayData` does not do that (even though is most likely more
efficient for many use-cases).
Note that even though rust `std::RawVec` offers a `with_capacity_zeroed`,
`std::Vec` does not expose that as a public API: `resize` and `resize_with` are
the public APIs to resize a vec, and none of them uses
`std::alloc::alloc_zeroed`, i.e. they also just call `std::ptr::write_bytes`.
I agree with you that `resize(len, 0)` can potentially be optimized when the
mutable buffer has zero capacity by calling `std::alloc::alloc_zeroed` instead
of `std::ptr::write_bytes`.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
