[
https://issues.apache.org/jira/browse/ARROW-7256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17125034#comment-17125034
]
Simon Watts edited comment on ARROW-7256 at 6/3/20, 3:06 PM:
-------------------------------------------------------------
Can I just add that we are finding places where the {{MemoryPool}} is not being
propagated to sub-components, due to default constructors created when using
{{default_memory_pool()}}.
While we are currently building against 0.15 we can disable
{{ARROW_MEMORY_POOL_DEFAULT}} (setting it to empty,
{{-DARROW_MEMORY_POOL_DEFAULT=""}}) to find these in header files. Although
that by itself is problematic as it leads to default constructors being created
- these cannot (easily) be avoided with just {{ARROW_MEMORY_POOL_DEFAULT}} to
pre-process on.
A better approach has been to replace {{default_memory_pool()}} for test
purposes with an implementation which returns a {{MemoryPool}} which +throws+
when asked to allocate or release memory (and logs a back-trace).
Our use-case is to ensure that we can use a custom {{MemoryPool}} which is more
performant in our performance critical workflows.
was (Author: sawatts):
Can I just add that we are finding places where the {{MemoryPool}} is not being
propagated to sub-components, due to default constructors created when using
{{default_memory_pool()}}.
While we are currently building against 0.15 we can disable
{{ARROW_MEMORY_POOL_DEFAULT}} (setting it to empty,
{{-DARROW_MEMORY_POOL_DEFAULT=""}}) to find these in header files. Although
that by itself is problematic as it leads to default constructors being created
- these cannot (easily) be avoided with just {{ARROW_MEMORY_POOL_DEFAULT}} to
pre-process on.
A better approach has been to replace {{default_memory_pool()}} for test
purposes with an implementation which returns an implementation which throws
when asked to allocate or release memory (and logs a back-trace).
Our use-case is to ensure that we can use a custom {{MemoryPool}} which is more
performant in our performance critical workflows.
> [C++] Remove ARROW_MEMORY_POOL_DEFAULT macro
> --------------------------------------------
>
> Key: ARROW-7256
> URL: https://issues.apache.org/jira/browse/ARROW-7256
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++
> Reporter: Wes McKinney
> Assignee: Krisztian Szucs
> Priority: Major
> Labels: pull-request-available
> Fix For: 0.17.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> As mentioned elsewhere in a JIRA I recall, we aren't testing adequately the
> CMake option for "no default memory pool", so it would either be better to
> require explicit memory pools or pass the default, rather than having a
> build-time option to set whether a default will be passed
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
