The run-time takes 5+ seconds to respond to Debugger.enable

[ahitrov]

Please, provide the details below:

Did you verify this is a real problem by searching Stack Overflow and the other open issues in this repo?

Yes

Tell us about the problem

The run-time takes 5+ seconds to respond to Debugger.enable

Please provide the following version numbers that your issue occurs with:

• CLI: 3.3.1

Please tell us how to recreate the issue in as much detail as possible.

This is reproducible with: https://github.com/NativeScript/template-master-detail-ts https://github.com/NativeScript/template-master-detail-ng https://github.com/NativeScript/template-master-detail-kinvey

against an Android Pixel.

clone https://github.com/NativeScript/template-master-detail-ts

cd template-master-detail-ts
tns platform add android
tns debug android --start

After receiving the Debugger.enable request the run-time would trigger scriptParsed events for all sources in the project (500+ files) first and only then would respond to the Debugger.enable request.

Starting a debug session against any of the listed projects would time out as the JavaScript debugger (Microsoft implementation) in Visual Studio has a non-configurable 5 second timeout on all requests.

In {N} Sidekick the debug session would not timeout but it would still take more than 5 seconds to initialize.

Please note that after receiving a response to Debugger.enable the JavaScript debugger in Visual Studio would start sending Debugger.setBreakpointByUrl for all pre-set breakpoints (again 5s timeout) and if the run-time does not respond to a request the breakpoint would remain inactive.

[petekanev]

Hey @ahitrov!

I'd like to note that we had a somewhat similar problem with the previous debugger inspector implementation using the node-inspector, because all files would be parsed and sent to the inspector in the beginning of the application execution, which as you would guess - clogs up the run loop and resulted in really bad debugging experience, as you would have to wait 10+ seconds on angular apps to start debugging.

When we made the switch to work with Chrome DevTools, the scripts would only appear in the sources panel as debuggable if, and when executed by the v8 virtual machine. That optimization alone meant that you would only see a small part of the application code immediately after startup, and would lazily parse and send the scripts to the inspector frontend.

The aforementioned benefit of the DevTools debugger is almost lost when a large chunk of scripts execute on application startup - application needs to run scripts, and send them to the inspector, as well as to handle the responses from the inspector - which makes the problem all the more visible. If the application was to just start, without connecting to a debugger - the boot time would be negligible. Similarly, if the debugger was to connect after the application has already started - the communication with the chrome devtools inspector will almost certainly go for under 5 seconds.

At this time we've not planned any efforts to look into offloading debugger communication to a background thread. What can be done however to improve the debugging experience for users using any of the 3 templates you listed, is to optimize the templates to not load everything on application boot up.

[Plamen5kov]

Update: A possible solution is in this commit. We'll test it out to see if it supports all needed functionalities.

Update to the above: Making the aforementioned changes does not make the debugger perform any faster.

[vtrifonov]

@ahitrov can you validate whether the issues still exists with the android@next?