Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow call stack response for TS repository #5645

Closed
isidorn opened this issue Apr 22, 2016 · 6 comments
Closed

Slow call stack response for TS repository #5645

isidorn opened this issue Apr 22, 2016 · 6 comments
Assignees
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality verified Verification succeeded
Milestone

Comments

@isidorn
Copy link
Contributor

isidorn commented Apr 22, 2016

Steps to Reproduce:

  1. git clone https://github.com/Microsoft/TypeScript.git
  2. npm install, npm install jake
  3. jake local
  4. set breakpoint in checker.ts:47
  5. Use the following launch.json
  6. Launch and notice getting call stack is slower than node inspector
  7. I originally specualted the large Locals are slowing us down, but they are loaded lazily and still the callStack takes a long time to respond. Not sure if we are doing something special on the debug adapter side for the call stack request
{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Launch",
            "type": "node",
            "request": "launch",
            "program": "${workspaceRoot}/src/compiler/tsc.ts",
            "stopOnEntry": false,
            "args": ["PATH TO ANY TS FILE"],
            "cwd": "${workspaceRoot}",
            "preLaunchTask": null,
            "runtimeExecutable": null,
            "runtimeArgs": [
                "--nolazy"
            ],
            "env": {
                "NODE_ENV": "development"
            },
            "externalConsole": false,
            "sourceMaps": true,
            "outDir": "${workspaceRoot}/built/local"
        }
    ]
}
@isidorn isidorn added the debug Debug viewlet, configurations, breakpoints, adapter issues label Apr 22, 2016
@weinand
Copy link
Contributor

weinand commented Apr 22, 2016

@isidorn does it make a difference if you only request one stackframe on a stoppedevent?

@weinand
Copy link
Contributor

weinand commented Apr 22, 2016

@isidorn what version of node is that?

@isidorn
Copy link
Contributor Author

isidorn commented Apr 22, 2016

@weinand It does not seem to make a difference if I request only 1 stack frame.
node version: 5.10.1

I also sometimes get the following errors
screen shot 2016-04-22 at 12 11 17

@weinand
Copy link
Contributor

weinand commented Apr 22, 2016

@isidorn does it make adifference if you do not request variables for stackframes at all?

@isidorn
Copy link
Contributor Author

isidorn commented Apr 22, 2016

@weinand if I do not request variables it is quite faster (a bit faster than node inspector)

@weinand
Copy link
Contributor

weinand commented Apr 22, 2016

Moved comment from #4951 by @joewood:

Hi @weinand, I did a bit of investigation.

I tried node-inspector and didn't see the issue. But, I did see the problem when I added my data structure to the watch window. Background here is that this module that I'm debugging has a large data structure loaded into memory. If I add this structure explicitly to node-inspector I see similar timeouts.

However, in VSCode I see the problem consistently, even with an empty watch window. So I assume the issue is related to what VSCode is watching by default (locals and context scope etc..) and what it's transferring each time I step through the debugger.

With that in mind I did a quick repro:

const faker = require("faker");

let data = {};

console.log("Running");

for(let n=0; n<100000; n++) {
    data["1" +n] = faker.name.firstName();
}

@weinand weinand added this to the May 2016 milestone May 4, 2016
@weinand weinand added the feature-request Request for new features or functionality label May 4, 2016
@egamma egamma mentioned this issue May 4, 2016
87 tasks
@weinand weinand assigned isidorn and unassigned weinand May 23, 2016
@isidorn isidorn added the verified Verification succeeded label May 24, 2016
@vscodebot vscodebot bot locked and limited conversation to collaborators Nov 18, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
debug Debug viewlet, configurations, breakpoints, adapter issues feature-request Request for new features or functionality verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

2 participants