[all-commits] [llvm/llvm-project] a5a2a5: [lldb][NFCI] Remove use of ConstString in Structur...

[Alex Langford via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: a5a2a5a3eca06998d9f71186db2ce78ae2716022
      https://github.com/llvm/llvm-project/commit/a5a2a5a3eca06998d9f71186db2ce78ae2716022
  Author: Alex Langford <alangford at apple.com>
  Date:   2023-09-14 (Thu, 14 Sep 2023)

  Changed paths:
    M lldb/include/lldb/Utility/StructuredData.h
    M lldb/source/Plugins/Platform/MacOSX/PlatformDarwin.cpp
    M lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
    M lldb/source/Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.cpp
    M lldb/source/Target/Target.cpp
    M lldb/source/Utility/StructuredData.cpp

  Log Message:
  -----------
  [lldb][NFCI] Remove use of ConstString in StructuredData

The remaining use of ConstString in StructuredData is the Dictionary
class. Internally it's backed by a `std::map<ConstString, ObjectSP>`.
I propose that we replace it with a `llvm::StringMap<ObjectSP>`.

Many StructuredData::Dictionary objects are ephemeral and only exist for
a short amount of time. Many of these Dictionaries are only produced
once and are never used again. That leaves us with a lot of string data
in the ConstString StringPool that is sitting there never to be used
again. Even if the same string is used many times for keys of different
Dictionary objects, that is something we can measure and adjust for
instead of assuming that every key may be reused at some point in the
future.

Quick comparisons of key data is likely not a concern with Dictionary,
but the use of `llvm::StringMap` means that lookups should be fast with
its hashing strategy.

Switching to a llvm::StringMap meant that the iteration order may be
different. To account for this when serializing/dumping the dictionary,
I added some code to sort the output by key before emitting anything.

Differential Revision: https://reviews.llvm.org/D159313