You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues-all@impala.apache.org by "Riza Suminto (Jira)" <ji...@apache.org> on 2020/02/22 00:28:00 UTC

[jira] [Comment Edited] (IMPALA-9382) Improve memory efficiency of RuntimeProfile objects

    [ https://issues.apache.org/jira/browse/IMPALA-9382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17042290#comment-17042290 ] 

Riza Suminto edited comment on IMPALA-9382 at 2/22/20 12:27 AM:
----------------------------------------------------------------

Looks like there is an ongoing effort to have singleton counter registration in IMPALA-7550 for documentation purpose.

[https://github.com/apache/impala/blob/master/be/src/util/runtime-profile-counters.h#L200]

I wonder if we can piggyback some performance optimization over that singleton registration object, according to your second point.


was (Author: rizaon):
Looks like there is an ongoing effort to have singleton counter registration in IMPALA-7550 for documentation purpose.

[https://github.com/apache/impala/blob/master/be/src/util/runtime-profile-counters.h#L139]

I wonder if we can piggyback some performance optimization over that singleton registration object, according to your second point.

> Improve memory efficiency of RuntimeProfile objects
> ---------------------------------------------------
>
>                 Key: IMPALA-9382
>                 URL: https://issues.apache.org/jira/browse/IMPALA-9382
>             Project: IMPALA
>          Issue Type: Sub-task
>          Components: Backend
>            Reporter: Tim Armstrong
>            Priority: Major
>
> RuntimeProfile trees can potentially stress the memory allocator and use up a lot more memory and cache than is really necessary:
> * std::map is used throughout, and allocates a node per map entry. We do depend on the counters being displayed in-order, but we would probably be better of storing the counters in a vector and lazily sorting when needed (since the set of counters is generally static after Prepare()).
> * We store the same counter names redundantly all over the place. We'd probably be best off using a pool of constant counter names (we could just require registering them upfront).
> There may be a small gain from switching thrift to using unordered_map, e.g. for the info strings that appear with some frequency in profiles.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org