[llvm] [llvm-symbolizer] nfc, use map instead of vector (PR #69552)

James Henderson via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 25 00:24:33 PDT 2023


================
@@ -82,12 +82,8 @@ class SymbolizableObjectFile : public SymbolizableModule {
     // Non-zero if this is an ELF local symbol. See the comment in
     // getNameFromSymbolTable.
     uint32_t ELFLocalSymIdx;
-
-    bool operator<(const SymbolDesc &RHS) const {
-      return Addr != RHS.Addr ? Addr < RHS.Addr : Size < RHS.Size;
-    }
   };
-  std::vector<SymbolDesc> Symbols;
+  std::map<uint64_t, SymbolDesc> Symbols;
----------------
jh7370 wrote:

The main benefit is the performance. As explained in the programming guide, `std::map` is not a very efficient data structure. Please do some runtime comparisons of the tool with and without this change, where you have for both a large number of elements and a small number. In particular, how does the runtime and memory usage compare before and after the change?

>  If I am understanding sorted vector right, each time when a new symbol is inserted to a sorted vector, it has to be sorted manually

The programming guide seems pretty clear in this regards: a sorted vector is the right approach if you want to insert lots of elements but don't care about the order during insertion. In other words, you haven't understood "sorted vector" correctly. The existing usage looks precisely like is described in the programmer's manual: lots of insertions, followed by a sort, and only then is the vector looked in:

> This approach works really well if your usage pattern has these two distinct phases (insert then query), and can be coupled with a good choice of [sequential container](https://llvm.org/docs/ProgrammersManual.html#ds-sequential).

> when add a new symbol, I need to know if there is any existing symbol that has same address.

Why do you need to know this _at insertion time_ rather than just sorting things differently?

https://github.com/llvm/llvm-project/pull/69552


More information about the llvm-commits mailing list