JakeDern commented on code in PR #10128:
URL: https://github.com/apache/arrow-rs/pull/10128#discussion_r4250618838
##########
arrow-ipc/src/writer.rs:
##########
@@ -318,23 +324,27 @@ where
{
fn write_record_batch(
&mut self,
- metadata: Vec<u8>,
- encoded_buffers: Vec<EncodedBuffer>,
+ metadata: &[u8],
+ encoded_buffers: &mut Vec<EncodedBuffer>,
body_len: usize,
- tail_pad: usize,
write_options: &IpcWriteOptions,
) -> Result<(usize, usize), ArrowError> {
let alignment = write_options.alignment;
let layout = MetadataLayout::new(metadata.len(), write_options);
self.write_continuation(write_options, layout.padded_metadata_len as
i32)?;
- self.write_all(&metadata)?;
+ self.write_all(metadata)?;
self.write_all(&PADDING[..layout.metadata_padding])?;
- for enc in &encoded_buffers {
+ for enc in encoded_buffers.iter_mut() {
self.write_all(enc.as_slice())?;
self.write_all(&PADDING[..pad_to_alignment(alignment,
enc.len())])?;
}
- self.write_all(&PADDING[..tail_pad])?;
+ // Clearing the buffers after the loop instead of draining the vec is
Review Comment:
I wish I had a good explanation as to why dropping the Buffers which contain
an Arc is less expensive this way, but I don't.
Maybe it's a benchmarking effect of some kind, but if so, it's only
reproducible on a Neoverse-V3 chip but not on a Neoverse-V2. My assumption was
that there is some performance quirk on that chip, but I can't say I know for
sure.
--
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]
