emkornfield commented on code in PR #9426:
URL: https://github.com/apache/arrow-rs/pull/9426#discussion_r2831259103
##########
arrow-array/src/builder/generic_bytes_builder.rs:
##########
@@ -110,6 +110,19 @@ impl<T: ByteArrayType> GenericByteBuilder<T> {
self.offsets_builder.push(self.next_offset());
}
+ /// Appends a value of type `T` into the builder `n` times.
+ ///
+ /// See [`Self::append_value`] for more panic information.
+ #[inline]
+ pub fn append_value_n(&mut self, value: impl AsRef<T::Native>, n: usize) {
+ let bytes = value.as_ref().as_ref();
+ for _ in 0..n {
+ self.value_builder.extend_from_slice(bytes);
Review Comment:
I didn't look closely at Rust, but from c++ there could be a potential
footgun (copied the reference below). So calling append_n with n=1 in a loop
was my concern if we ended up using reserve. It sounds like Rust might might
make stronger guarantees (but there is wiggle room)
> Correctly using reserve() can prevent unnecessary reallocations, but
inappropriate uses of reserve() (for instance, calling it before every
[push_back()](https://en.cppreference.com/w/cpp/container/vector/push_back.html)
call) may actually increase the number of reallocations (by causing the
capacity to grow linearly rather than exponentially) and result in increased
computational complexity and decreased performance. For example, a function
that receives an arbitrary vector by reference and appends elements to it
should usually not call reserve() on the vector, since it does not know of the
vector's usage characteristics.
--
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.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
