StackTraceRequest is very slow after version 4.0.2

[crt-31]

Processing StackTraceRequest has become orders of magnitude slower since version 4.0.2, almost to a point where debugging is unusable. We are using Metals/Bloop, and everytime we debug break, the StackTraceRequest is sent and can take 5 to 10 seconds to process.

The regression seems to be caused by the new feature to add presentation hint for each method in the callstack.

The culprit seems to be in JdiExtensions.isLazyGetter which calls jdi.Method.argumentTypes(). jdi.Method.argumentTypes() seems to be an expensive function as it queries the host for all the fields. Doing this on every method in callstack is slowing things down.

https://github.com/scalacenter/scala-debug-adapter/blob/b2800f01a41b2dfc5feaa68a256538c973d89d11/modules/core/src/main/scala/ch/epfl/scala/debugadapter/internal/stacktrace/JdiExtensions.scala#L45-L49

I don't have any great solutions to fix this, other than finding a way to not have to call isLazyGetter all the time, or maybe a config option to turn off presentationHint? Just ideas.

[adpi2]

Thanks for the report!

I will need more information to address this issue:

• Does it happen on Scala 2.12, 2.13 or 3? Have you tried other Scala versions?
• What JVM do you use? Does it happen on other JVMs?
• Have you tried the latest version of the Scala Debug Adapter?
• Why do you think isLazyGetter is the culprit?

[crt-31]

• Issue happens on scala 2.13.14 and 2.13.10... Haven't tried any other versions
• Using Correto 17.0.11 & Hotspot 17.0.6.10
• Confirmed issue happens on latest main of Scala Debug Adapter
• Used Flight Recorder to narrow down to the isLazyGetter function. The slowness went away when I commented that line out.

Investigating the code further, it made sense since method.argumentTypes() sends request to the host and waits for response... also the problem appears to be exasperated by presense of anonymous functions such as for comprehensions and lambdas.

Note, we are running a large application, I don't notice it in small applications.

[adpi2]

Thanks for the details! That's very helpful.

Note, we are running a large application, I don't notice it in small applications.

If you use VSCode, it only loads the top 10 frames and then you need to click to expand the entire stack. In other code editors, I don't know, maybe there is a similar feature that you can enable. But anyway I'll see if I can avoid this method.argumentTypes call.

[crt-31]

Thanks for addressing this. (Also, we are using VSCode & Metals)

[adpi2]

Also, we are using VSCode & Metals

Then it should only load 10 frames, which should not be slow. So I guess it becomes slow only when you expand the entire stack?

[crt-31]

I'm not expanding or even really touching the vs code stack frame ui.

[adpi2]

@crt-31 Could you show me a screenshot of stacktrace that is slow to load? I'd like to determine if there is a pattern that makes it slow.

[crt-31]

@adpi2: Here you go. Here is an example of a (redacted) callstack that is real slow and one that is fast.

SLOW CALLSTACK

FAST CALLSTACK

Also, I see that VS Code requests 20 requests at a time... but not relevant... still its still slow.