[
https://issues.apache.org/jira/browse/ARROW-3406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393423#comment-17393423
]
Weston Pace commented on ARROW-3406:
------------------------------------
This is often done during packet processing. Chapter 5 of
https://fast.dpdk.org/doc/pdf-guides-2.2/prog_guide-2.2.pdf explains how one
such pool works. Although packet processing is a bit of a different field.
Packets are usually very small (a few kB) and arrive at a very fast rate. I
agree with Antoine that this would only be useful (not redundant with
jemalloc/mimalloc) if you are using fixed size blocks and this is fairly common
with I/O. Although for disk I/O I would guess the I/O time will swamp any
allocation time. For memory mapped I/O this is a non-issue. For network I/O
via Flight I think this kind of optimization would be covered by gRPC. I think
the same is true of S3 where we receive the buffer from the AWS SDK.
Without any kind of evidence that memory pressure/allocation is becoming a
bottleneck I'm not sure it makes sense to work on this.
> [C++] Create a caching memory pool implementation
> -------------------------------------------------
>
> Key: ARROW-3406
> URL: https://issues.apache.org/jira/browse/ARROW-3406
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Affects Versions: 0.11.0
> Reporter: Antoine Pitrou
> Priority: Minor
> Labels: query-engine
>
> A caching memory pool implementation would be able to recycle freed memory
> blocks instead of returning them to the system immediately. Two different
> policies may be chosen:
> * either an unbounded cache
> * or a size-limited cache, perhaps with some kind of LRU mechanism
> Such a feature might help e.g. for CSV parsing, when reading and parsing data
> into temporary memory buffers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
