Remote debug is so slow

[Ricbet]

I think it should be here.

If there are many threads (e.g 200).
isCollected() and name() will send the command packet to the target vm through JDI and wait for reply.
That would request 200*2 times. I don’t know if it can be optimized

[testforstephen]

This may cause lots of roundtrip with the debuggee, but it's not the only place that needs to be optimized. The main problem is the underlying JPDA is chatty and not efficient for remote debugging. There is not a good way to solve this problem completely.

At the comment we recommend you to take a look at VS Code remote development support.

[github-actions]

Hi @Ricbet, I'm an AI Support assistant here to help with your issue. While the team reviews your request, I wanted to provide some possible tips and documentation that might help you in the meantime.

Based on the JDI chatty nature there is unfortunately no way to eliminate per-thread round trips for isCollected() and name(). Possible workarounds:

• Run the Debug Adapter on the same host as the target JVM (e.g. via VS Code Remote SSH or Remote Development) to avoid high-latency network hops between your machine and the debuggee.
• Limit or lazily fetch thread names: only call thread.name() when the client actually needs to display a specific thread instead of prefetching all names.

High-confidence references:

• Remote Java debug is slow – JDI is inherently chatty; recommendation to use VS Code Remote SSH so the adapter communicates locally: Remote Java debug is slow vscode-java-debug#596 (comment)
• Chatty JPDA roundtrips are the root cause; full mitigation is not possible today: Remote debug is so slow. vscode-java-debug#704 (comment)

The team will respond to your issue shortly. I hope these suggestions are helpful in the meantime. If this comment helped you, please give it a 👍. If the suggestion was not helpful or incorrect, please give it a 👎. Your feedback helps us improve!