Slow processing of variables on hitting a breakpoint

[RedMickey]

Hello,
I'm a maintainer of React Native Tools VS Code extension. The extension is used for debugging React Native applications. Under the hood the extension uses vscode-js-debug debugger to debug javascript apps.

Describe the bug
After the update of VS Code to the version 1.57.0 we detected that processing of variables on the first hitting of a breakpoint can take quite a long time. However further breakpoints hittings are handled fine. We found out that such behavior appeared after the implementation of Support for renamed identifiers in sourcemaps feature in this PR. We looked through CDP logs and revealed that now js-debug retrieves the whole bundled code of the application (via "Debugger.getScriptSource" method) and processes it. We assume that this could take a long time.

Jun-16-2021.10-48-45.mp4

To Reproduce
The issue can be reproduced using a node attach scenario, but it requires some preparations.

Steps to reproduce the behavior:

1. Prepare development environment for Android React Native following this guide
2. Create a React Native app using the command:

   npx react-native init AwesomeProject
   

3. We prepared a special version of RNT extension, in which we suppressed attachment to an application in debugging scenarios. You can download this VSIX and install it.
4. Open your RN project in VS code and create Debug Android debugging configuration

   {
     "name": "Debug Android",
     "cwd": "${workspaceFolder}",
     "type": "reactnative",
     "request": "launch",
     "platform": "android"
   }
   

5. Open App.js file and set a breakpoint on the 62 line (return statement)
6. Run the Debug Android debugging scenario and wait until you see something like this in Debug console

   Starting debugger app worker.
   Attaching to the application
   Launching the application
   Established a connection with the Proxy (Packager) to the React Native application
   Debugger worker loaded runtime on port 9468
   

   The debugging scenario should launch the RN app on an Android emulator.
7. Enable debugging in the launched application following this guide. If after that an error is shown in the app, click Reload button.
8. Create the Attach debugging scenario

   {
     "type": "pwa-node",
     "request": "attach",
     "name": "Attach",
     "port": 9468,
     "sourceMaps": true,
     "continueOnAttach": true,
     "resolveSourceMapLocations": [
       "!**/debuggerWorker.js"
     ]
   }
   

   The port should be the same as a debugger worker has.
9. Run the Attach scenario
10. Continue on the first technical breakpoint (the debuggerWorker process is launched in --inspect-brk mode)
11. After that, your previously set breakpoint should be reached

Probable solution
We are not sure about the solution, but it might make sense to add a special parameter to debugging configurations to enable/disable the “Support for renamed identifiers in sourcemaps” feature. So, users can configure it if they really need additional processing of variables while debugging.

Log File
Js-debug logs:
vscode-debugadapter-f39647b7.json.gz
CDP logs:
currentCDPlogs.txt
previousCDPlogs_vs_code_1_56.txt

VS Code Version: 1.57.0

[connor4312]

I've made a change so that we only request source content if names are present in the sourcemap. Previously we were eagerly getting it for each file. Let me know if that resolves it for you.

[RedMickey]

Hi @connor4312 and thanks for your answer.
I've tried out the new version of js-debug and it seems the issue still persists. I inspected the index.map file provided by the RN app and it contained a lot of names arrays. Therefore, createFromSourceMap function is called, it seems that it takes most of the processing time (about 3-8 sec.).
I believe that this is a useful feature, and it seems to be the expected behavior if there are names arrays in the .map file. I'm just a little worried about the processing time.

[nthtrung09it]

Experiencing the same issue. It takes about 2 minutes to be able to continue debugging.
Version: 1.57.1
MacOS 11.5 Beta (20G5042c)

[connor4312]

You can now set sourceMapRenames: false in the launch config to disable this functionality

[connor4312]

I pinged the author for verification. You can also try the Launch Minified Program in the demo folder https://github.com/microsoft/vscode-js-debug/tree/main/demos/node.

To verify:

1. Open the demo folder https://github.com/microsoft/vscode-js-debug/tree/main/demos/node
2. Run the Launch Minified Program configuration, and set a breakpoint here:

   vscode-js-debug/demos/node/main.js

   Line 19 in 5831107

   console.log(`hello, took ${Date.now() - start}ms`);

   . Verify the variable names are their original, source names in the "Variable" view
3. Add sourceMapRenames: false in the launch configuration
4. Do step 2 again. The variables name should now be their minified names (from main.min.js)

[lagnat]

@connor4312 Is there any followup ticket for the performance issue here? Disabling sourceMapRenames is not a great workaround.

[connor4312]

If you have any ideas on how to make sourcemap names mapping work better in a way that doesn't require requesting the compile script, I'm happy to hear it, but I don't think it's possible.

[lagnat]

Truthfully I don't know enough about this so these ideas may be nonsense. All I could think of would be to process the map files on a worker thread right away vs. waiting for the first breakpoint. Another thought would be some kind of cache with incremental processing of map files.