golang
debug: consider calling ListPackageVars from variable request instead of scopes request
As being discussed in https://github.com/microsoft/vscode-go/issues/2210, the feature of showing global variables when debugging requires calling ListPackageVars which is expensive in many cases. @segevfiner has a suggestion that we can call ListPackageVars just from the variable request instead of being called from scopes request.
I havent investigated whether this is possible and if so, whether it makes any difference to perf. This issue is to do the investigation and any follow up required
cc @polinasok, @quoctruong
Per spec, variables request retrieves the children. That's when we preload and analyze the type of each child, so we can create a record and a reference for compound types (otherwise its a leaf with reference 0). This also allows us to display an informative value string with children details even before the user expands. Since a scope essentially acts like an outer variable, it is handled the same way and things are indeed loaded before the expand button is actually clicked, even though we don't put those details in the top-level string. There is a TODO in the delve code to reconsider this and delay loading: https://github.com/go-delve/delve/blob/5842c1fe9e4009ebf020839fe4901a24c930ecb3/service/dap/server.go#L2034-L2041. I think the cost aspect should be less relevant now because we no longer pay the price for sending the retrieved variables data over the network preemptively, but either way profiling is our friend in such cases to avoid premature optimizations at the expense of special cases and logic surgeries. At the same time this could be a good time to introduce another layer to support all Globals, not just main, which could help delay loading until the user actual clicks on Globals:
> Globals # use expansion to call s.debugger.CurrentPackage to load all
> package main # use expansion to filter the cached values and send back just for the package
> package foo
