Lazy loading of locals / thread-specific variable loading?

[etiennecollin]

Hello!

I’m currently using nvim-dap-ui and running into performance issues when debugging programs with many threads over a remote connection (~40 ms latency).

In that setup, when all threads attempt to load their locals simultaneously, stepping through code can become very slow, and the UI may take a long time to populate variables (multiple seconds to more than a minute).

I have not tried nvim-dap-view yet, but I’m very interested in it. I wasn’t able to find information in the documentation about how it handles loading of debugger values, so I wanted to ask:

• Does it load locals only for the currently stopped thread?
• Are variables fetched lazily / on demand (e.g., when expanding a scope or selecting a thread)?
• Or does it eagerly request data for all threads?

A lazy-loading approach (only fetching data for the active thread unless explicitly requested) would significantly improve responsiveness in high-latency, multi-threaded debugging scenarios like mine.

If this is already supported, it might be worth highlighting in the documentation; it would be a strong advantage over other UIs.

Thanks for your work on this plugin!

[igorlfs]

Hey,

In that setup, when all threads attempt to load their locals simultaneously, stepping through code can become very slow, and the UI may take a long time to populate variables (multiple seconds to more than a minute).

I need to understand your setup a little better. There could be multiple things at play here. Without the specifics, these are just guesses:

1. Can you reproduce the slowness without nvim-dap-ui? By default, nvim-dap injects the variables for each scope within the stopped thread. You mention this issue only happens in a multi-thread setup, but this could be the underlying cause.
2. Some scopes are labeled as expensive. These are "ignored" by nvim-dap, nvim-dap-ui and nvim-dap-view. It could be the case that whatever adapter you're using is mistakenly not labeling some scopes as expensive. This may sound unlikely, but I had this exact problem with the js-debug adapter.
3. Do you have any performance info for vscode? As in: if vscode were to face the same penalties, it might be tricky to get improvements. On the other hand, if vscode runs smoothly, it means something is going on with neovim's DAP "stack".

Does it load locals only for the currently stopped thread?

Yep.

Are variables fetched lazily / on demand (e.g., when expanding a scope or selecting a thread)?

The variables are fetched "on demand" in the sense that the expansions are not eagerly loaded (this would be straight up expensive for no reason). But overall, performance hasn't been a major concern. In fact, out of correctness, there's lots of "redundant" work (which I could into specifics if you'd like to hear).

Or does it eagerly request data for all threads?

As mentioned, the data for scopes is only fetched for the current, stopped thread.

it might be worth highlighting in the documentation

I wouldn't label nvim-dap-view as "blazingly fast" (or something like that). Certainly, there are lots of improvements to be made. I recommend giving it a shot and opening an issue if you run into blatant performance issues. I'm not aware of anyone reporting that nvim-dap-view provides a "nice experience" for scenarios like yours, so it could be the case that it just sucks currently.

Thanks for your work on this plugin!

❤️

[etiennecollin]

Hi!
Thanks for your answer! I will try to give you more details...

I was able to test nvim-dap-view, and it’s already significantly faster than nvim-dap-ui in my setup. As far as I understand (I haven't looked at the source code), the difference seems to come from the fact that nvim-dap-ui eagerly loads data (across threads), whereas nvim-dap-view is much more conservative (which is great!). I have not tested nvim-dap without a UI, but that would be the next step. I could also test with VSCode, I just need to install it 😆 .

For reference, the behaviour I hit with nvim-dap-ui is described here: rcarriga/nvim-dap-ui#429, specifically in this comment rcarriga/nvim-dap-ui#429 (comment).

That said, I’m working with a c++ application with around 10-20 threads. I use gdb to debug a remote target that runs gdbserver (~80 ms RTT), where performance is dominated by the number of round-trips. Even relatively small increases in request count have a noticeable impact.

In that context, I think further improvements would come from pushing laziness even further and only fetch data for what is strictly visible (again, I have not read the source code, maybe that behaviour is already partly/fully implemented):

• Only load the current thread A, unless the user goes to the thread tab and selects another thread B. Once thread B is selected, no need to load things from thread A.
  • This is already implemented according to your last message!
• Only load scopes if the user is on the scopes tab.
• If the user has watches open, it would be preferable to only evaluate/load watches, which is typically much cheaper than loading full local scopes.
• When a struct is in scope, the data it "contains" should only be loaded when the struct is explicitly expanded.
• The scope should only be loaded for the current stack trace "level" you are stopped at. When the user uses dap.up() and dap.down(), then the new scope should be loaded.

Overall, dap-view already provides a much better experience in this kind of setup, but I wanted to share these observations in case there’s room to make it even more efficient for high-latency remote debugging scenarios.

Thanks once again for your answer and great plugin 😄 It really saved my day at work this week!

[igorlfs]

I was able to test nvim-dap-view, and it’s already significantly faster than nvim-dap-ui in my setup.

🚀

Only load scopes if the user is on the scopes tab.

Do note that nvim-dap always fetches the scopes anyway (and the top level variables, which we could actually reuse, but up until now I didn't bother with)

it would be preferable to only evaluate/load watches

Yes, that's how it works

When a struct is in scope, the data it "contains" should only be loaded when the struct is explicitly expanded.

Likewise.

The scope should only be loaded for the current stack trace "level" you are stopped at. When the user uses dap.up() and dap.down(), then the new scope should be loaded.

I think this drastically reduces the usefulness of having the scopes in the first place. For instance, callbacks create a new scope (usually with a very limited amount of variables). Showing only these would make no sense. And again, nvim-dap already eagerly populates all (non expensive) scopes anyway.

Thanks once again for your answer and great plugin 😄 It really saved my day at work this week!

I'm glad you liked it!

[igorlfs]

Side note: there's another open discussion about showing the scopes for all threads, you might be interested.