ArrowBuf copying from GetReadableBuffer causes slowness

[SuperManJin]

Describe the usage question you have. Please include as many useful details as possible.

I'm using Arrow Flight and discovered an extra copy action while testing performance impact.

ReadableBuffer readableBuffer = fastPath ? getReadableBuffer(stream) : null; if (readableBuffer != null) { readableBuffer.readBytes(buf.nioBuffer(0, size)); }

The flame graph shows that after enabling zero_copy, ArrowBuf copying from GetReadableBuffer causes slowness.
Why does this copy occur?
Or is it because arrowbuf needs to manage its own memory, so the ownership must be transferred from netty?

Component(s)

FlightRPC

[raulcd]

I've moved this issue to the apache/arrow-java repository instead of the original apache/arrow.

[lidavidm]

That flamegraph seems to be cut off - can you show a screenshot that includes the Arrow frames? (I'm assuming that readBytes at the bottom is from

arrow-java/flight/flight-core/src/main/java/org/apache/arrow/flight/grpc/GetReadableBuffer.java

Line 91 in 156b465

readableBuffer.readBytes(buf.nioBuffer(0, size));

? )

That said I think this copy is likely unavoidable - we need a contiguous buffer and gRPC doesn't necessarily give it to us. We'd only be able to avoid it if it was actually a single buffer underneath that gRPC isn't giving to us already for some reason. (And from a quick glance through the code, I don't think the gRPC code is doing this optimization for us, if it even applies - as I recall, grpc-cpp has a similar issue and it's rare that gRPC actually only has a single buffer; something about their network stack tends to give a a set of smaller buffers that must be reassembled.)