Change:
} } } <ins> /** * Keeps track of events for threads, and cancels any previous operations for * a thread when the thread goes into a new state. Currently, the operations a thread has are: * * - started * - stopped * - continue * - exited * * In each case, the new state preempts the old state, so we don't need to * queue work, just cancel old work. It's up to the caller to make sure that * no UI effects happen at the point when the `token` is cancelled. */ export class ThreadStatusScheduler extends Disposable { /** * An array of set of thread IDs. When a 'stopped' event is encountered, the * editor refreshes its thread IDs. In the meantime, the thread may change * state it again. So the editor puts a Set into this array when it starts * the refresh, and checks it after the refresh is finished, to see if * any of the threads it looked up should now be invalidated. */ private pendingCancellations: Set<number | undefined>[] = []; /** * Cancellation tokens for currently-running operations on threads. */ private readonly threadOps = this._register(new DisposableMap<number, CancellationTokenSource>()); /** * Runs the operation. * If thread is undefined it affects all threads. */ public async run(threadIdsP: Promise<number[]>, operation: (threadId: number, ct: CancellationToken) => Promise<unknown>) { const cancelledWhileLookingUpThreads = new Set<number | undefined>(); this.pendingCancellations.push(cancelledWhileLookingUpThreads); const threadIds = await threadIdsP; // Now that we got our threads, // 1. Remove our pending set, and // 2. Cancel any slower callers who might also have found this thread for (let i = 0; i < this.pendingCancellations.length; i++) { const s = this.pendingCancellations[i]; if (s === cancelledWhileLookingUpThreads) { this.pendingCancellations.splice(i, 1); break; } else { for (const threadId of threadIds) { s.add(threadId); } } } if (cancelledWhileLookingUpThreads.has(undefined)) { return; } await Promise.all(threadIds.map(threadId => { if (cancelledWhileLookingUpThreads.has(threadId)) { return; } this.threadOps.get(threadId)?.cancel(); const cts = new CancellationTokenSource(); this.threadOps.set(threadId, cts); return operation(threadId, cts.token); })); } /** * Cancels all ongoing state operations on the given threads. * If threads is undefined it cancel all threads. */ public cancel(threadIds?: readonly number[]) { if (!threadIds) { for (const [_, op] of this.threadOps) { op.cancel(); } this.threadOps.clearAndDisposeAll(); for (const s of this.pendingCancellations) { s.add(undefined); } } else { for (const threadId of threadIds) { this.threadOps.get(threadId)?.cancel(); this.threadOps.deleteAndDispose(threadId); for (const s of this.pendingCancellations) { s.add(threadId); } } } } } </ins>

Discussion:
Type: <bPerformance Issue</bWhen I step into my code (NodeJS), I noticed lately that the debugger is slower upon stepping in or over. I don't recall having this issue before though. It's a slight lag. I tried clearing my cache but that seemed to have no effect. VS Code version: Code 1.79.2 (, 2023-06-14T08:57:04.379Z) OS version: WindowsNT x64 10.0. Modes: <details<summarySystem Info</summary </details<details<summaryWorkspace Info</summary</details<details<summaryExtensions (9)</summaryExtensionVersion ------ vscode-css-formatter1.0.2 classdiagram-ts0.1.67 jsonviewer1.3.2 javascript-ejs-support1.3.3 gitlens14.0.1 vscode-firefox-debug2.9.8 debug-visualizer2.4.0 hexeditor1.9.11 php-debug1.32.1 </details<!-- generated by issue reporter --
Just following up. I actually reformatted my computer and upgraded to Windows 11 if that helps. And I am still getting lag with the step cursor (specifically with the Node debugger). When using the step cursor and XDebug, it's normal responsive speed.
/jsDebugLogs
Please collect trace logs using the following instructions:
It doesn't look like you ran a "step into" when you recorded those logs. Please do so so I can see what's going on.
Sorry about that. More data should be available in this log file.
There's a lot going on there. I think your case might have already been fixed by You can try out the of the debugger and see.
Oh sorry I did too much lol. Ok, I can live with this until the next fix. I'll keep an eye out for this on the next update. If I notice the debugger is still slow after next official update, I will just open this ticket again.
Also my title is a little inaccurate. It's not slow on just "step into". But also "step over" as well.
Sorta like VSCode decided to throttle the keystrokes. When the instruction is executed, its normal speed. But when I keep pressing F10 its not as responsive as it used to be.

For example, when I press F10 10 times, I expect responsiveness. But lately there seems to be latency between keystrokes.
There will always be some latency because events are queued and ultimately multiple round trips through the debugger and back to are required. But from the logs it looks like your rapid strokes might be getting you into the "bad state" I referenced in the PR where spooky things start happening. I'll close this for now, please comment if you hit this on nightly/in the next release (scheduled for 6 to 7 days from now)
I haven't tried the nightly release because I figured I would wait. But it's been awhile now, and I am still experiencing this problem. Debugging is still slow on version 1.81.0
Please grab another log file if you're able. Thanks!
Sure, I just debugged a very simple hello world app, barebones. Looping through an array from 1 through 10.
Can you grab a record of your screen during this? is useful. Also, please run so we can see when you trigger actions using keybindings, if any.
Yes, no problem. Please see the issue via the gif. If you need a video for something smoother, let me know. But this should give you an idea of the delay I have when I step through. Please note that the delay was never this severe. !
Thanks, I saw similar. It looks there is no longer a problem on the JS debugger side; it seems like vscode is being a bit slow to process things. For example, in the log, I see requests for stacktrace information come in for the previous event even after session has already been continued. Rob, might be a side-effect of the queuing a few iterations ago?
Just FYI, this is also a node.JS problem too. My example is only showing client side, but I work in Node all the time, and its the same problem.
Just checking for a status update on this issue.
<!-- AUTHORVERIFICATIONREQUEST --This bug has been fixed in the latest release of ! you can help us out by commenting if things are now working as expected.

If things still don't seem right, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
Just as I was accepting that this debugger would always have latency issues, I get this notification today. I immediately installed Insiders, from someone who uses this style of debugging all the time, I can confirm this has been fixed! I will continue to test of course, but so far this is the fastest I've ever seen the step into debugger work, even before this had been a verifiable problem. Thanks for addressing this. As someone who debugs code 90% of the time, this was pleasant surprise to see fixed! /verified