[
https://issues.apache.org/jira/browse/ARROW-3192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16687321#comment-16687321
]
Bryan Cutler commented on ARROW-3192:
-------------------------------------
Thanks [~wesmckinn], yes I think these would affect Spark. I'll try to take a
closer look at this when I can.
> [Java] Implement "ArrowBufReadChannel" abstraction and alternate
> MessageSerializer that uses this
> -------------------------------------------------------------------------------------------------
>
> Key: ARROW-3192
> URL: https://issues.apache.org/jira/browse/ARROW-3192
> Project: Apache Arrow
> Issue Type: Improvement
> Components: Java
> Reporter: Wes McKinney
> Priority: Major
> Fix For: 0.13.0
>
>
> The current MessageSerializer implementation is wasteful when used to read an
> IPC payload that is already in-memory in an {{ArrowBuf}}. In particular,
> reads out of a {{ReadChannel}} require memory allocation
> *
> https://github.com/apache/arrow/blob/master/java/vector/src/main/java/org/apache/arrow/vector/ipc/message/MessageSerializer.java#L569
> *
> https://github.com/apache/arrow/blob/master/java/vector/src/main/java/org/apache/arrow/vector/ipc/message/MessageSerializer.java#L290
> In C++, we have abstracted memory allocation out of the IPC read path so that
> zero-copy is possible. I suggest that a similar mechanism can be developed
> for Java to improve deserialization performance for in-memory messages. The
> new interface would return {{ArrowBuf}} when performing reads, which could be
> zero-copy when possible, but when not the current strategy of allocate-copy
> could be used
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
