[
https://issues.apache.org/jira/browse/ARROW-10351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313074#comment-17313074
]
Yibo Cai commented on ARROW-10351:
----------------------------------
Did a very rudiment test to interleave data compressing with data sending.
Looks it can improve performance.
A thread is spawned to prepare next record batch when main thread is sending
current record batch.
Basically, I separated [these two
lines|https://github.com/apache/arrow/blob/master/cpp/src/arrow/ipc/writer.cc#L999-L1000
] into two different functions running in their own threads.
For streams = 1, I see stable improvement of speed (1200 -> 1700) and latency
(90 ->70).
No improvement when streams >= 4. I'm testing on one skylake server with 32
cores and 2 numa nodes. See POC code for details.
POC code at
[https://github.com/cyb70289/arrow/commit/24a55f71325d280a3be42cbbcd41c392471c8af6]
> [C++][Flight] See if reading/writing to gRPC get/put streams asynchronously
> helps performance
> ---------------------------------------------------------------------------------------------
>
> Key: ARROW-10351
> URL: https://issues.apache.org/jira/browse/ARROW-10351
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++, FlightRPC
> Reporter: Wes McKinney
> Priority: Major
>
> We don't use any asynchronous concepts in the way that Flight is implemented
> now, i.e. IPC deconstruction/reconstruction (which may include compression!)
> is not performed concurrent with moving FlightData objects through the gRPC
> machinery, which may yield suboptimal performance.
> It might be better to apply an actor-type approach where a dedicated thread
> retrieves and prepares the next raw IPC message (within a Future) while the
> current IPC message is being processed -- that way reading/writing to/from
> the gRPC stream is not blocked on the IPC code doing its thing.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
