Since latest update I'm getting "It's taking a while to configure your breakpoints." message

[MarByteBeep]

Issue Type: Bug

I have a Javascipt only application, with no transpiling or conversion going on. My launch.json is like this:

{
	"type": "node",
	"request": "launch",
	"name": "Fetch",
	"program": "${workspaceFolder}/exec.js",
	"args": ["fetch.js"],
	"outputCapture": "std",
	"skipFiles": [
		"${workspaceFolder}/node_modules/**/*.js",
		"${workspaceFolder}/lib/**/*.js",
		"<node_internals>/**/*.js"
	]
},

Exec.js is just a wrapper that executes a method in fetch.js.

Starting this program now sometimes takes a long time and I get the following warning:

It's taking a while to configure your breakpoints. You can speed this up by updating the 'outFiles' in your launch.json.

I only have a few breakpoints, nor was this causing a problem before the update. What's changed? And why am I advised to update outFiles while I'm only running a simple javascript script?

VS Code version: Code - Insiders 1.65.0-insider (82a8bec, 2022-02-10T05:16:36.093Z)
OS version: Windows_NT x64 10.0.19044
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz (8 x 2494)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	7.89GB (2.72GB free)
Process Argv	--crash-reporter-id 82b0b2fc-aa31-4181-9863-56bf85ed5e36
Screen Reader	no
VM	0%

Extensions: none

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368:30146709
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30422396
pythontb:30258533
pythonvspyt551:30291412
pythonptprofiler:30281269
vshan820:30294714
pythondataviewer:30285072
vscod805cf:30301675
pythonvspyt200:30323110
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
pythonvs932:30404738
wslgetstartedc:30421358
vsclayoutctrt:30405800
dsvsc008:30436272
pythonvspyt640:30426300
vsbas813:30436447
vscscmwlcmc:30428972
azactmsal:30432848

[maowenzhang]

We met same issue at VSCode 1.64.2, it becomes super slow to get debug started. Tried a workaround is adding outFiles in the launch.json config.
Also tried go back to old VSCode 1.63.2, which doesn't have this issue.

[connor4312]

/jsDebugLogs

[MarByteBeep]

I've sent the log to that mail address. I've tried parsing it using your online tool, and it seemed to work, but I couldn't see some sort of share button. If you need anything else, let me know!

[connor4312]

@roblourens did something change in ripgrep in the last release? It looks like the time is all spent in findTextInFiles. The only change js-debug made is that where previously it would have searched with

{ include: new vscode.RelativePattern(workspaceFolder, '**/*.js'), exclude: '**/node_modules/**' }

it now also includes an excluding explicitly using the workspace folder, like

{ include: new vscode.RelativePattern(workspaceFolder, '**/*.js'), exclude: `**/node_modules/**,${workspaceFolder}/**/node_modules/**` }

[cdaringe]

For the Javascript Debug Terminal, I'm not sure which attach configuration to plop trace into. Any advice--I'd like to do some profiling as well :)

[roblourens]

No change to ripgrep or relevant search code that I can think of

[knaos]

I confirm our team has the same issue in the latest release.

[knaos]

Following the advice from issue #140427 to start VsCode with --disable-gpu flag fixes the problem.

EDIT: This is NOT fixing the problem.

[connor4312]

That is quite surprising... can anyone else in the thread verify whether the same steps fix it for them?

[MarByteBeep]

Well, it's complicated. I tried the following sequence:

PS C:\svn> code
PS C:\svn> code
PS C:\svn> code
PS C:\svn> code  --disable-gpu
PS C:\svn> code  --disable-gpu
PS C:\svn> code  --disable-gpu
PS C:\svn> code
PS C:\svn> code

And with each start I loaded a project and pressed F5. The first 3 boots all gave me the breakpoint message. Then I used the --disable-gpu flag: no BP message anymore. But I didn't get it anymore for the subsequent boots either, with or without flag. Perhaps the flag reset something internally? Or perhaps it's a red herring :)

Random thought here. That --disable-gpu solution did make me think about a problem I experienced with other software as well: Multi monitor support through a docking station. I know that rendering software such as DaVince Resolve have major issues with supporting this properly, resulting in various weird bugs. If it indeed turns out to be --disable-gpu, could it be something like this?