search

vshaxe / hashlink-debugger

Visual Studio Code Debugger for Haxe/HashLink applications
https://hashlink.haxe.org/
MIT License
57 stars 23 forks source link

Slow debugger #100

Closed ncannasse closed 2 years ago

ncannasse commented 3 years ago

Following #97, the debugger is now very very slow. Might be related to the build of native libraries or some other change. I don't think the debugger code itself is responsible for the change in performances.

rcstuber commented 3 years ago

Since deasync messes with the event loop, it might be a good candidate for such issues?

ncannasse commented 3 years ago

Uhm, deasync is used by Sys API implementation to implement some network operations, but the slowdown also occur when the process is paused, when for example reading data from the process, seems more like a ffi-napi issue.

ncannasse commented 3 years ago

@rcstuber tell me if you can confirm by printing a complex value (like a map or array with lots of values) if it's a lot slower with latest ffi-napi VS previous version (might require to downgrade node as well). I think this can be reproduced with nodejs commandline version (without any VSCode)

rcstuber commented 3 years ago

Sorry I didn't have time yet to test this. I can however confirm that it's currently horribly slow to query class fields (i.e. h2d.Object base) and that the old version I'm running trough the "debugServer" option is much faster (it does not run in Electron's node service though, but a normal Node process)

rcstuber commented 3 years ago

Nevermind my previous comment regarding updating npm packages, I was on an outdated commit, however the debugger still freezes when hitting a breakpoint on MacOS with VSCode's electron version being 12.0.13. Standalone adapter running inside normal node still works.

ghost commented 2 years ago

On Linux Mint 20.2, VSCode 1.61.2, hashlink-debugger 1.1.2, the debugger breaks on the first breakpoint only. Trying to continue does nothing, though I'm able to step through statements. But in 20 second intervals between each step.

The Hashlink windows is always empty and unresponsive after starting or trying to continue, and reaching the first breakpoint or stepping after it maxes out 2 cores for 20 seconds before completing a step.

Attaching to a hl --debug 6112 --debug-wait out/output.hl runs the project successfully but without stopping at any breakpoints despite many being set.

You could say that the debugger works just fine as long as you don't have any breakpoints set ¯_(ツ)_/¯

rcstuber commented 2 years ago

@Ateknia This relates to https://github.com/vshaxe/hashlink-debugger/issues/77

ncannasse commented 2 years ago

This was indeed a bug with recent node versions when marshalling typed arrays between the JS context and the native library. We fixed that by implementing our own native extension (in hldebug-wrapper) that returns data using strings (sadly) so there's no big slowdown being done by nodejs. v1.3.0+ includes this fix.