================
@@ -374,25 +377,40 @@ void DebugNamesDWARFIndex::GetFullyQualifiedType(
m_fallback.GetFullyQualifiedType(context, callback);
}
+bool DebugNamesDWARFIndex::SameAsEntryATName(
+ llvm::StringRef query_name, const DebugNames::Entry &entry) const {
+ auto maybe_dieoffset = entry.getDIEUnitOffset();
+ if (!maybe_dieoffset)
+ return false;
+
+ // [Optimization] instead of parsing the entry from dwo file, we simply
+ // check if the query_name can point to an entry of the same DIE offset.
+ // This greatly reduced number of dwo file parsed and thus improved the
+ // performance.
+ for (const DebugNames::Entry &query_entry :
+ entry.getNameIndex()->equal_range(query_name)) {
+ auto query_dieoffset = query_entry.getDIEUnitOffset();
+ if (!query_dieoffset)
+ continue;
+
+ if (*query_dieoffset == *maybe_dieoffset) {
+ return true;
+ } else if (*query_dieoffset > *maybe_dieoffset) {
+ // The pool entries of the same name are sequentially cluttered together
+ // so if the query name from `query_name` is after the target entry, this
+ // is definitely not the correct one, we can stop searching.
----------------
jeffreytan81 wrote:
@labath, let me see if I can explain well:
The purpose of `SameAsEntryATName(query_name, entry)` is to check whether the
`pool entry` has the name `query_name`.
Name table encodes data like this:
```
<name_table_entry for "query_name"> --> <consecutive_list_of_pool_entry>
```
In the name table, the `SameAsEntryATName(query_name, entry)` function in this
PR attempts to verify if the `entry` is within a list of
`<consecutive_list_of_pool_entry>` above.
The "incorrectly implemented check" in this PR tries to bail out early by
checking whether the first `Entry Offset` pointed to by `<name_table_entry for
"query_name">` is greater than or equal to the `entry`'s offset in the "Entry
Pool". If this condition is met, it indicates that the `entry` is located
before the `<consecutive_list_of_pool_entry>` in the "Entry Pool", meaning it
cannot be part of the `<consecutive_list_of_pool_entry>` we are searching for.
Consequently, the code can bail out early without iterating through the
`<consecutive_list_of_pool_entry>` to check for a match.
Per testing, this early bail out does not affect much performance (I guess
because `<consecutive_list_of_pool_entry>` is small for most `query_name`), so
it is not an important optimization. For split dwarf, avoid touching dwo files
is the key performance mover in this PR.
https://github.com/llvm/llvm-project/pull/108907
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
