alamb commented on code in PR #8694:
URL: https://github.com/apache/arrow-rs/pull/8694#discussion_r2470790178
##########
arrow-array/src/array/byte_view_array.rs:
##########
@@ -512,18 +512,72 @@ impl<T: ByteViewType + ?Sized> GenericByteViewArray<T> {
};
}
- // 3) Allocate exactly capacity for all non-inline data
- let mut data_buf = Vec::with_capacity(total_large);
+ struct GcCopyGroup {
+ total_buffer_bytes: usize,
+ total_len: usize,
+ }
+
+ let gc_copy_groups = if total_large > i32::MAX as usize {
+ // Slow-path: need to split into multiple copy groups
+ let mut groups = vec![];
+ let mut current_length = 0;
+ let mut current_elements = 0;
- // 4) Iterate over views and process each inline/non-inline view
- let views_buf: Vec<u128> = (0..len)
- .map(|i| unsafe { self.copy_view_to_buffer(i, &mut data_buf) })
- .collect();
+ for view in self.views() {
+ let len = *view as u32;
Review Comment:
I am not sure how you would make this much faster - I think the code needs
to find the locations to split in any event
##########
arrow-array/src/array/byte_view_array.rs:
##########
@@ -512,18 +512,71 @@ impl<T: ByteViewType + ?Sized> GenericByteViewArray<T> {
};
}
- // 3) Allocate exactly capacity for all non-inline data
- let mut data_buf = Vec::with_capacity(total_large);
+ struct GcCopyGroup {
+ total_buffer_bytes: usize,
+ total_len: usize,
+ }
+
+ let gc_copy_groups = if total_large > i32::MAX as usize {
+ // Slow-path: need to split into multiple copy groups
+ let mut groups = vec![];
+ let mut current_length = 0;
+ let mut current_elements = 0;
- // 4) Iterate over views and process each inline/non-inline view
- let views_buf: Vec<u128> = (0..len)
- .map(|i| unsafe { self.copy_view_to_buffer(i, &mut data_buf) })
- .collect();
+ for view in self.views() {
+ let len = *view as u32;
+ if len > MAX_INLINE_VIEW_LEN {
+ if current_length + len > i32::MAX as u32 {
+ // Start a new group
+ groups.push(GcCopyGroup {
+ total_buffer_bytes: current_length as usize,
+ total_len: current_elements,
+ });
+ current_length = 0;
+ current_elements = 0;
+ }
+ current_length += len;
+ current_elements += 1;
+ }
+ }
+ if current_elements != 0 {
+ groups.push(GcCopyGroup {
+ total_buffer_bytes: current_length as usize,
+ total_len: current_elements,
+ });
+ }
+ groups
+ } else {
+ let gc_copy_group = GcCopyGroup {
+ total_buffer_bytes: total_large,
+ total_len: len,
+ };
+ vec![gc_copy_group]
Review Comment:
I know it is probably a small thing, but could you please avoid this new
allocation for the common case where there is a single buffer? Perhaps by
creating the data bufs directly via a function call rather than a loop over the
array
##########
arrow-array/src/array/byte_view_array.rs:
##########
@@ -512,18 +512,71 @@ impl<T: ByteViewType + ?Sized> GenericByteViewArray<T> {
};
}
- // 3) Allocate exactly capacity for all non-inline data
- let mut data_buf = Vec::with_capacity(total_large);
+ struct GcCopyGroup {
Review Comment:
I found this somewhat confusing at first as it is just deferring the
creation of the view buffers.
I think the code would be clearer (and faster) if you simply created the new
buffers directly (with a branch for when the total length was too large)
##########
arrow-array/src/array/byte_view_array.rs:
##########
@@ -1404,6 +1463,55 @@ mod tests {
}
}
+ #[test]
+ fn test_gc_huge_array() {
Review Comment:
I ran this test on my mac M3 and it takes 1.5 seconds so I think it is ok
```
running 1 test
test array::byte_view_array::tests::test_gc_huge_array ... ok
test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 578 filtered
out; finished in 1.58s
```
I also verified that without the code in this PR, the test fails like:
```
---- array::byte_view_array::tests::test_gc_huge_array stdout ----
thread 'array::byte_view_array::tests::test_gc_huge_array' panicked at
arrow-array/src/array/byte_view_array.rs:1444:9:
assertion `left != right` failed: gc with huge buffer should not consolidate
data into a single buffer
left: 1
right: 1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
--
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]
