================
@@ -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.
----------------
felipepiovezan wrote:
Yup, I agree with @labath interpretation of the spec here.
Here's what I would suggest:
1. Make a patch just changes the implementation of `SameAsEntryATName`. This
will benefit your use case (dwo) by itself and we can measure the perf impact
of not being able to relying on the sorting of entries in all cases.
Then we can branch the work into two parallel lines of investigation:
1.1. [If sorting entries turns out to be important] we can create a series of
patches exploring the augmentation string idea from @labath
1.2. One patch for `GetNamespacesWithParents` and then one patch for
`GetTypesWithParents`
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
