-
Notifications
You must be signed in to change notification settings - Fork 14.3k
[DebugNames] Use hashes to quickly filter false positives #79755
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DebugNames] Use hashes to quickly filter false positives #79755
Conversation
The current implementation of DebugNames is _only_ using hashes to compute the bucket number. Once inside the bucket, it reverts back to string comparisons, even though not all hashes inside a bucket are identical. This commit changes the behavior so that we check the hash before comparing strings. Such check is so important that it speeds up a simple benchmark by 20%. In other words, the following expression evaluation time goes from 1100ms to 850ms. ``` bin/lldb \ --batch \ -o "b CodeGenFunction::GenerateCode" \ -o run \ -o "expr Fn" \ -- \ clang++ -c -g test.cpp -o /dev/null &> output ``` (Note, these numbers are considering the usage of IDX_parent)
@llvm/pr-subscribers-debuginfo Author: Felipe de Azevedo Piovezan (felipepiovezan) ChangesThe current implementation of DebugNames is only using hashes to compute the bucket number. Once inside the bucket, it reverts back to string comparisons, even though not all hashes inside a bucket are identical. This commit changes the behavior so that we check the hash before comparing strings. Such check is so important that it speeds up a simple benchmark by 20%. In other words, the following expression evaluation time goes from 1100ms to 850ms.
(Note, these numbers are considering the usage of IDX_parent) Full diff: https://github.com/llvm/llvm-project/pull/79755.diff 1 Files Affected:
diff --git a/llvm/lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp b/llvm/lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp
index 03ad5d133caddf..a1a1ac093aa5c1 100644
--- a/llvm/lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp
+++ b/llvm/lib/DebugInfo/DWARF/DWARFAcceleratorTable.cpp
@@ -937,9 +937,11 @@ DWARFDebugNames::ValueIterator::findEntryOffsetInCurrentIndex() {
return std::nullopt; // Empty bucket
for (; Index <= Hdr.NameCount; ++Index) {
- uint32_t Hash = CurrentIndex->getHashArrayEntry(Index);
- if (Hash % Hdr.BucketCount != Bucket)
+ uint32_t HashAtIndex = CurrentIndex->getHashArrayEntry(Index);
+ if (HashAtIndex % Hdr.BucketCount != Bucket)
return std::nullopt; // End of bucket
+ if (HashAtIndex != Hash)
+ continue;
NameTableEntry NTE = CurrentIndex->getNameTableEntry(Index);
if (NTE.getString() == Key)
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a solid improvement!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🥳
Nice! |
The current implementation of DebugNames is _only_ using hashes to compute the bucket number. Once inside the bucket, it reverts back to string comparisons, even though not all hashes inside a bucket are identical. This commit changes the behavior so that we check the hash before comparing strings. Such check is so important that it speeds up a simple benchmark by 20%. In other words, the following expression evaluation time goes from 1100ms to 850ms. ``` bin/lldb \ --batch \ -o "b CodeGenFunction::GenerateCode" \ -o run \ -o "expr Fn" \ -- \ clang++ -c -g test.cpp -o /dev/null &> output ``` (Note, these numbers are considering the usage of IDX_parent) (cherry picked from commit 69cb99f)
The current implementation of DebugNames is only using hashes to compute the bucket number. Once inside the bucket, it reverts back to string comparisons, even though not all hashes inside a bucket are identical.
This commit changes the behavior so that we check the hash before comparing strings. Such check is so important that it speeds up a simple benchmark by 20%. In other words, the following expression evaluation time goes from 1100ms to 850ms.
(Note, these numbers are considering the usage of IDX_parent)