[ 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 <impala-public-jenk...@cloudera.com> Tested-by: Impala Public Jenkins <impala-public-jenk...@cloudera.com> > 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: issues-all-unsubscr...@impala.apache.org For additional commands, e-mail: issues-all-h...@impala.apache.org