Slow call stack response for TS repository

[isidorn]

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"
        }
    ]
}

[weinand]

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

[weinand]

@isidorn what version of node is that?

[isidorn]

@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

[weinand]

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

[isidorn]

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

[weinand]

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();
}