This is an archive of the discontinued LLVM Phabricator instance.

Add "indexedVariables" to variables with lots of children.
ClosedPublic

Authored by clayborg on May 10 2022, 5:02 PM.

Details

Summary

Prior to this fix if we have a really large array or collection class, we would end up always creating all of the child variables for an array or collection class. If the number of children was very high this can cause delays when expanding variables. By adding the "indexedVariables" to variables with lots of children, we can keep good performance in the variables view at all times. This patch will add the "indexedVariables" key/value pair to any "Variable" JSON dictionairies when we have an array of synthetic child provider that will create more than 100 children.

We have to be careful to not call "uint32_t SBValue::GetNumChildren()" on any lldb::SBValue that we use because it can cause a class, struct or union to complete the type in order to be able to properly tell us how many children it has and this can be expensive if you have a lot of variables. By default LLDB won't need to complete a type if we have variables that are classes, structs or unions unless the user expands the variable in the variable view. So we try to only get the GetNumChildren() when we have an array, as this is a cheap operation, or a synthetic child provider, most of which are for showing collections that typically fall into this category. We add a variable reference, which indicates that something can be expanded, when the function "bool SBValue::MightHaveChildren()" is true as this call doesn't need to complete the type in order to return true. This way if no one ever expands class variables, we don't need to complete the type.

Diff Detail

Event Timeline

clayborg created this revision.May 10 2022, 5:02 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 10 2022, 5:02 PM
Herald added a subscriber: arphaman. · View Herald Transcript
clayborg requested review of this revision.May 10 2022, 5:02 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 10 2022, 5:02 PM
yinghuitan added inline comments.May 10 2022, 6:00 PM
lldb/tools/lldb-vscode/JSONUtils.cpp
1035

It sucks that indexedVariables has be to be filled at container variable creation time to determine the children number.
A better DAP design would be VSCode asking for children count at container expansion time. Then we can always call GetNumChildren() since all children will be enumerated anyway.

1055

Do you think if we can handle the map cases? Assuming there is a formatter for unordered_map<>, if we can detect it and provide paging as well.

lldb/tools/lldb-vscode/VSCode.cpp
46 ↗(On Diff #428537)

I assume this is your test change? Revert.

clayborg updated this revision to Diff 428789.May 11 2022, 3:26 PM

Remove logging change from VSCode.cpp that was accidentally left in.

clayborg added inline comments.May 11 2022, 3:29 PM
lldb/tools/lldb-vscode/JSONUtils.cpp
1035

Agreed, but not much we can do there.

1055

All of the collection classes emit very similar stuff with indexed names.

std::unordered_map<std::string, std::string> u = {
        {"RED","#FF0000"},
        {"GREEN","#00FF00"},
        {"BLUE","#0000FF"}
    };

Then when we debug:

(std::unordered_map<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::hash<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >) u = size=3 {
  [0] = {
    __cc = (first = "BLUE", second = "#0000FF")
  }
  [1] = {
    __cc = (first = "GREEN", second = "#00FF00")
  }
  [2] = {
    __cc = (first = "RED", second = "#FF0000")
  }
}

So it will work for unordered_map.

yinghuitan accepted this revision.May 11 2022, 4:03 PM
This revision is now accepted and ready to land.May 11 2022, 4:03 PM