[ 
https://issues.apache.org/jira/browse/IMPALA-4132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tim Armstrong resolved IMPALA-4132.
-----------------------------------
       Resolution: Fixed
    Fix Version/s: Impala 2.12.0
                   Impala 3.0

commit 1890230246bc197a4d246915a1128a0b852f425a
Author: Gabor Kaszab <gaborkas...@cloudera.com>
Date:   Tue Nov 21 02:12:51 2017 +0100

    IMPALA-4132: Use -fno-omit-frame-pointer
    
    Using -fno-omit-frame-pointer would keep the frame pointers for
    functions in the register. As a result we expect more useful stack
    traces to be produced.
    
    For testing performance benchmark was executed on TPC-H and TPC-DS
    without any significant discrepancy from the baseline results.
    (For the specific measures check the attachments in the Jira.)
    
    Change-Id: Ib7d0d88ba015a847356ed0274fe91017b98cb941
    Reviewed-on: http://gerrit.cloudera.org:8080/8612
    Reviewed-by: Tim Armstrong <tarmstr...@cloudera.com>
    Tested-by: Impala Public Jenkins


> Consider using -fno-omit-frame-pointer in release builds
> --------------------------------------------------------
>
>                 Key: IMPALA-4132
>                 URL: https://issues.apache.org/jira/browse/IMPALA-4132
>             Project: IMPALA
>          Issue Type: Improvement
>          Components: Infrastructure
>    Affects Versions: Impala 2.7.0
>            Reporter: Silvius Rus
>            Assignee: Gabor Kaszab
>            Priority: Major
>              Labels: breakpad, supportability
>             Fix For: Impala 3.0, Impala 2.12.0
>
>         Attachments: targeted_report.txt, tpcds_report.txt, 
> tpcds_unmodified_report.txt, tpch_nested_report.txt, tpch_report.txt
>
>
> We're currently building with -fomit-frame-pointer, which can lead to cryptic 
> stack traces.
> Switching to -fno-omit-frame-pointer will produce better stack traces but 
> cost some performance.  In my past experience, on x86-64 the penalty was 
> around 0.5% (though on different code and with a different register 
> allocator) which I think is a reasonably tradeoff but in corner cases it can 
> be higher.  So we'd need to qualify this change through a perf regression run 
> (both benchmarks and primitives).



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to