Crash with large source maps #1911
Comments
|
That appears to be in this function https://github.com/TooTallNate/proxy-agents/blob/b133295fd16f6475578b6b15bd9b4e33ecb0d0b7/packages/data-uri-to-buffer/src/index.ts#L8-L39 While that's not super fast (the base64 decoder I wrote for vscode itself is 3x faster) I don't see it being that slow. Parsing 100MB of data through that takes about 3.5 seconds, but it's not a crash and that would be "very big" as far as sourcemaps go... How big are your sourcemaps? |
I saw in microsoft/vscode-js-debug#1911 that base64 decoding of a data URI was taking a bit of time. This PR feature-detects the presence of a global `Buffer` to use native decoding when running in Node.js, which is about 25x faster on a 10MB data URI than the JS implementation in the library. I have a bit of a hack in order to test both paths when running tests, happy to change it if desired :)
|
There are many, a lot of them are small, but there are also a few big ones, with the largest being around 50MiB, though it's not really used in the source of the script I was trying to debug. |
|
Once my linked PR goes in, decoding should be much faster (25x or so). You may also see improvement in the latest nightly with #1916, which fixes some cases where sourcemap memory was leaked (the previous implementation was wasm-based and required manual deallocation of memory, which didn't always happen.) |
* Make decoding of base64 data URIs faster I saw in microsoft/vscode-js-debug#1911 that base64 decoding of a data URI was taking a bit of time. This PR feature-detects the presence of a global `Buffer` to use native decoding when running in Node.js, which is about 25x faster on a 10MB data URI than the JS implementation in the library. I have a bit of a hack in order to test both paths when running tests, happy to change it if desired :) * use conditional exports * fix test import * fix node test import, and set stringToBuffer encoding * Create few-adults-rhyme.md --------- Co-authored-by: Nathan Rajlich <[email protected]>
* Make decoding of base64 data URIs faster I saw in microsoft/vscode-js-debug#1911 that base64 decoding of a data URI was taking a bit of time. This PR feature-detects the presence of a global `Buffer` to use native decoding when running in Node.js, which is about 25x faster on a 10MB data URI than the JS implementation in the library. I have a bit of a hack in order to test both paths when running tests, happy to change it if desired :) * use conditional exports * fix test import * fix node test import, and set stringToBuffer encoding * Create few-adults-rhyme.md --------- Co-authored-by: Nathan Rajlich <[email protected]>
|
Please let me know if you see this again on the nightly build or VS Code >1.86. Thanks! |
* Make decoding of base64 data URIs faster I saw in microsoft/vscode-js-debug#1911 that base64 decoding of a data URI was taking a bit of time. This PR feature-detects the presence of a global `Buffer` to use native decoding when running in Node.js, which is about 25x faster on a 10MB data URI than the JS implementation in the library. I have a bit of a hack in order to test both paths when running tests, happy to change it if desired :) * use conditional exports * fix test import * fix node test import, and set stringToBuffer encoding * Create few-adults-rhyme.md --------- Co-authored-by: Nathan Rajlich <[email protected]>
* Make decoding of base64 data URIs faster I saw in microsoft/vscode-js-debug#1911 that base64 decoding of a data URI was taking a bit of time. This PR feature-detects the presence of a global `Buffer` to use native decoding when running in Node.js, which is about 25x faster on a 10MB data URI than the JS implementation in the library. I have a bit of a hack in order to test both paths when running tests, happy to change it if desired :) * use conditional exports * fix test import * fix node test import, and set stringToBuffer encoding * Create few-adults-rhyme.md --------- Co-authored-by: Nathan Rajlich <[email protected]>
Describe the bug
On trying to debug using the "JavaScript Debug Terminal", a project that has quite a bunch of very large source maps, the debugger, debug adapter & extension host crash with: "Debug adapter process has terminated unexpectedly (Extension host shut down)".
To Reproduce
Steps to reproduce the behavior:
My project is proprietary, so I can't provide it directly as a repro, but I will see if I can mock something similar that exhibits the same behavior if you can't figure out what's going on from logs alone.
Log File
vscode-debugadapter-28a26b60.json.gz
It also sometimes produces a cpuprofile in the "Window" log of VS Code:
exthost-d35bd5.cpuprofile
VS Code Version: 1.85.1
Additional context
Wasn't able to figure out exactly why it crashes. As in, if it hangs the extension host, and gets terminated by something, OOM, or something else... Any ideas how to figure this out?
The text was updated successfully, but these errors were encountered: