You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@impala.apache.org by "Tim Armstrong (JIRA)" <ji...@apache.org> on 2018/02/14 21:20:00 UTC
[jira] [Resolved] (IMPALA-4132) Consider using
-fno-omit-frame-pointer in release builds
[ 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 <ga...@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 <ta...@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)