[
https://issues.apache.org/jira/browse/IMPALA-12390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17758657#comment-17758657
]
ASF subversion and git services commented on IMPALA-12390:
----------------------------------------------------------
Commit d96341ed537a3e321d5fa6a0235ab06b5d9169a2 in impala's branch
refs/heads/master from Joe McDonnell
[ https://gitbox.apache.org/repos/asf?p=impala.git;h=d96341ed5 ]
IMPALA-12393: Fix inconsistent hash for TimestampValue in DictEncoder
Currently, DictEncoder uses the default hash function for
TimestampValue, which means it is hashing the entire
TimestampValue struct. This can be inconsistent, because
TimestampValue contains some padding that may not be zero
in some cases. For TimestampValues that are part of a Tuple,
the padding is zero, so this is mainly present in test cases.
This was discovered when fixing a Clang Tidy performance-for-range-copy
warning by iterating with a const reference rather than
making a copy of the value. DictTest.TestTimestamps became
flaky with that change, because the hash was no longer
consistent. The copy must have had consistent content for
the padding through the iteration, but the const reference
did not.
This adds a template specialization of the Hash function
for TimestampValue. The specialization uses TimestampValue::Hash(),
which hashes only the non-padding pieces of the struct. This
also includes the change to dict-test.cc that uncovered the
issue. This fix is mostly to unblock IMPALA-12390.
Testing:
- Ran dict-test in a loop for a few hundred iterations
- Hand tested inserting many timestamps into a Parquet table
with dictionary encoding and verified that the performance didn't
change.
Change-Id: Iad86e9b0f645311c3389cf2804dcc1a346ff10a9
Reviewed-on: http://gerrit.cloudera.org:8080/20396
Tested-by: Impala Public Jenkins <[email protected]>
Reviewed-by: Daniel Becker <[email protected]>
Reviewed-by: Michael Smith <[email protected]>
> Enable performance related clang-tidy checks
> --------------------------------------------
>
> Key: IMPALA-12390
> URL: https://issues.apache.org/jira/browse/IMPALA-12390
> Project: IMPALA
> Issue Type: Improvement
> Components: Backend
> Affects Versions: Impala 4.3.0
> Reporter: Joe McDonnell
> Assignee: Joe McDonnell
> Priority: Major
>
> clang-tidy has several performance-related checks that seem like they would
> be useful to enforce. Here are some examples:
> {noformat}
> /home/joemcdonnell/upstream/Impala/be/src/runtime/types.h:313:25: warning:
> loop variable is copied but only used as const reference; consider making it
> a const reference [performance-for-range-copy]
> for (ColumnType child_type : col_type.children) {
> ~~~~~~~~~~ ^
> const &
> /home/joemcdonnell/upstream/Impala/be/src/catalog/catalog-util.cc:168:34:
> warning: 'find' called with a string literal consisting of a single
> character; consider using the more effective overload accepting a character
> [performance-faster-string-find]
> int pos = object_name.find(".");
> ^~~~
> '.'
> /home/joemcdonnell/upstream/Impala/be/src/util/decimal-util.h:55:53: warning:
> the parameter 'b' is copied for each invocation but only used as a const
> reference; consider making it a const reference
> [performance-unnecessary-value-param]
> static int256_t SafeMultiply(int256_t a, int256_t b, bool may_overflow) {
> ~~~~~~~~ ^
> const &
> /home/joemcdonnell/upstream/Impala/be/src/codegen/llvm-codegen.cc:847:5:
> warning: 'push_back' is called inside a loop; consider pre-allocating the
> vector capacity before the loop [performance-inefficient-vector-operation]
> arguments.push_back(args_[i].type);
> ^{noformat}
> In all, they seem to flag things that developers wouldn't ordinarily notice,
> and it doesn't seem to have too many false positives. We should look into
> enabling these.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
