[
https://issues.apache.org/jira/browse/IMPALA-11110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17522506#comment-17522506
]
ASF subversion and git services commented on IMPALA-11110:
----------------------------------------------------------
Commit 8910f62ba3200657186c35eb516ac9bb41a684e1 in impala's branch
refs/heads/master from Daniel Becker
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=8910f62ba ]
IMPALA-11242: Impala cluster doesn't start when building with debug_noopt
IMPALA-11110 added the 'debug_noopt' build option but after building
Impala with it, starting the Impala cluster fails:
[...]
File "/home/user/Impala/tests/common/environ.py", line 196, in
validate_build_flags
raise Exception("Unknown build type {0}".format(build_type))
Exception: Unknown build type debug_noopt
Adding a new 'DEBUG_NOOPT' entry to 'VALID_BUILD_TYPES' in
tests/common/environ.py solves the issue.
Change-Id: I388c24f7ed194eac73cecf041a0337a87bd806f6
Reviewed-on: http://gerrit.cloudera.org:8080/18412
Reviewed-by: Impala Public Jenkins <[email protected]>
Tested-by: Impala Public Jenkins <[email protected]>
> Enable basic optimizations for debug builds
> -------------------------------------------
>
> Key: IMPALA-11110
> URL: https://issues.apache.org/jira/browse/IMPALA-11110
> Project: IMPALA
> Issue Type: Improvement
> Components: Infrastructure
> Affects Versions: Impala 4.1.0
> Reporter: Joe McDonnell
> Assignee: Joe McDonnell
> Priority: Major
> Fix For: Impala 4.1.0
>
>
> Currently, Impala debug builds use no optimizations. Some optimizations can
> interfere with debuggability, and the debug builds prioritize debuggability.
> However, running without optimizations means the binary is much slower.
> GCC has a debug-friendly optimization level -Og, which enables optimizations
> that do not interfere with debugging. This may provide a way to get the
> debuggability needed while having faster runtimes. See
> [https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html]
> In testing this, the binaries are definitely faster. Core test runtimes are
> reduced by about 25 minutes. Exhaustive test runtimes are reduced by over an
> hour.
> The extra optimization enables compiler passes that produce more debugging
> information. This means that the binaries have more debug info, which make
> them larger. This extra information is likely related to variable tracking
> (i.e. fvar-tracking-assignments), which is recommended for maximum
> debuggability (but may not be strictly necessary for how we use it). See
> [https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html]
> {noformat}
> Binary size for impalad (unstripped)
> Without -Og: 519345880
> With -Og: 709527368
> Binary size for impalad (stripped)
> Without -Og: 164500024
> With -Og: 105873184{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
