This is an archive of the discontinued LLVM Phabricator instance.

[lldb][NFCI] Remove use of ConstString in StructuredData
ClosedPublic

Authored by bulbazord on Aug 31 2023, 2:46 PM.

Details

Summary

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.

Diff Detail

Event Timeline

bulbazord created this revision.Aug 31 2023, 2:46 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 31 2023, 2:46 PM
Herald added a subscriber: mgrang. · View Herald Transcript
bulbazord requested review of this revision.Aug 31 2023, 2:46 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 31 2023, 2:46 PM
fdeazeve added inline comments.Aug 31 2023, 3:14 PM
lldb/include/lldb/Utility/StructuredData.h
436

Since we are touching this line anyway, could you replace this with

for (StringRef key : llvm::make_first_range(m_dict))

This has a bit less cognitive burden IMO

438

Also since you are touching this line, one could argue for it to be deleted and folded into std::make_shared<String>(Key);

I don't feel strongly about it though, it could also be more appropriate for a separate commit

448

This line in particular also shows why I think this patch is appropriate: even queries were introducing strings into the pool

537

This is not equivalent to the old code, right? The previous code would overwrite the contents if the key already existed.

lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
2035

This is another win: the old code was calling StringRef(const char*), which has to iterate over the entire string to find the null terminating character.

lldb/source/Plugins/SymbolVendor/MacOSX/SymbolVendorMacOSX.cpp
248

same win here

lldb/source/Target/Target.cpp
3866

we talked about it in private, but I feel like stating this publicly: does anyone know if this was legal? object->GetStringValue().str() creates a temporary std::string. And then we call c_str() and pass that to the Printf function. Does the temporary std::string have its lifetime extended?

lldb/source/Utility/StructuredData.cpp
173

I thought pairs had operator < defined already?

bulbazord marked an inline comment as done.Aug 31 2023, 3:29 PM
bulbazord added inline comments.
lldb/include/lldb/Utility/StructuredData.h
448

Yes, this also was happening in HasKey as well.

537

Oh, good catch. I think what I want is insert_or_assign. Will update.

lldb/source/Utility/StructuredData.cpp
173

Oh, I didn't even think to check. I'll try it and update if I don't need to define this lambda.

bulbazord marked 7 inline comments as done.

Address feedback from @fdeazeve

lldb/include/lldb/Utility/StructuredData.h
436

Unfortunately no, llvm::make_first_range assumes that you can refer to first on an iterator, but first is actually a method to be called. The iterator code will have to stay for now.

bulbazord added inline comments.Sep 14 2023, 10:23 AM
lldb/source/Utility/StructuredData.cpp
251–253

Oh I can remove this lambda too -- Let me update.

Remove unneeded lambda

This revision is now accepted and ready to land.Sep 14 2023, 10:36 AM