Angular eval bundles are not optimized and very slow

[jpike88]

Describe the bug
We are experiencing slow launch/initialisation/reload times with both our Chrome extension since upgrading to VSCode 1.47.0

This new module must be the culprit, as this slowdown has occurred across 3 different machines, two are Mac and one is Ubuntu. Caused up to 30 seconds of time between hot reloads on two computers, and caused a more powerful computer's fans to spin up hard for long periods of time.

I want a way to use the old debugger, I don't need new features if it's going to cause such a big performance hit.

Downgrading to VSCode 1.46 brings back normal performant behavior.

1 months in Insiders is way too little time to iron out the kinks, this was pushed out too early. Should have at least had a way for people to opt out.

Why did you guys swap them out anyway? If it ain't broke...

[connor4312]

You can use the option debug.javascript.usePreview: false to use the old debugger, but this will eventually go away as js-debug stabilizes.

Please provide a trace log using these instructions and I can take a look at why it's being slow for you:

If you're able to, add "trace": true to your launch.json and reproduce the issue. The location of the log file on your disk will be written to the Debug Console. Share that with us.

⚠️ This log file will not contain source code, but will contain file paths. You can drop it into https://microsoft.github.io/vscode-pwa-analyzer/index.html to see what it contains. If you'd rather not share the log publicly, you can email it to connor@xbox.com

[jpike88]

I'll instruct our devs to do this and attach the logs to this issue ASAP

[AlbertoMontalesi]

Here's the log i've got

vscode-chrome-debug.txt

[connor4312]

@AlbertoMontalesi thanks for the log, but that's from the old debugger. Can you take a log without setting debug.javascript.usePreview: false?

[AlbertoMontalesi]

@connor4312
My bad

debug.json.zip

[connor4312]

Great, thanks. I see what's happening -- we actually have an optimized mode for these kinds of scenarios, but it looks like your sourcemaps start with ng:/// rather than webpack:/// so our logic wasn't kicking in. I don't get this case in a new Angular project from the CLI (there they start with webpack:///) so I can't easily test it locally, please confirm whether it works for you.

You can wait until 5 PM PST today to grab the latest nightly build, or manually installed (Install from VSIX command) this pack I manually built: https://memes.peet.io/img/js-debug-nightly-issue-598.vsix

[AlbertoMontalesi]

@connor4312 From an initial test it seesm that the nightly build works fine and performance is back to normal. I noticed that everytime a hot reload occurs the debug panel opens by itself, it didn't occur with the old debugger, it's a bit annoying because i have to keep closing it manually. Not sure if it's related to this extension or not.

[connor4312]

It looks like the setting debug.openDebug defaults to openOnSessionStart -- and when you reload the page, the previous page's session is destroyed and a new one is created, so this is technically doing the right thing. openOnFirstSessionStart seems like what you want and might be a more reasonable default. I'll open an issue to see if we should change that.

[AlbertoMontalesi]

@connor4312 awesome thanks, i've set it now to openOnFirstSessionStart