I’ve been using the debugger with some success in VSCode, but today it was incredibly slow. Like 30 seconds to 2 minutes to step from one line to the next, even when the lines in question didn’t seem to be doing much, e.g., computing a set difference with 2 arrays of under 10 symbols each.
I had set a breakpoint in the code and then did @run from the REPL.
The highlighted line usually advanced pretty promptly, but the progress indicator in the explorer view kept spinning, and the new data created by the line did not display until the end of the waiting period.
During this time one CPU was at the max running julia. There were also times when VSCode showed high CPU use.
Any suggestions?
The most obvious difference between this and earlier sessions is that some of the local variables were very large DataFrames (~ 38k x 100). I never opened up the browser on them, but if the code was trying to precompute what they would look like if I did, that might explain the delay. Although wouldn’t the display show the usual truncated view in any case?
Another possibility is that my use of ProfileView (I think, definitely some package) is causing trouble. It comes with warning that using GTK on Windows may slow things down by a lot, even 100 fold. I have a using directive for it, but never ran it during the session. And this is no change from earlier.
It also seemed to me that revise was not picking up my changes; I did a lot of stopping and restarting the REPL. However, a significant number of my changes where type changes, which I don’t think it can handle.
After many minutes of stepping through a program I got a notice that the extension had crashed. This was the only time it crashed in a handful of sessions using it. It was the longest session.
VSCode says I have the Julia 1.0.8 extension; VSCode is 1.50.0; Julia is 1.5.1.
Running on 64 bit Win 10 Enterprise Version 1809 Build 17763
stepping over setdiff(a,b) is quite fast for me (after the initial compilation).
But the interpreter is orders of magnitude slower than compiled code. Try clicking the “Compiled Mode” checkbox to step over things you don’t care about.
What does compiled mode do, or, better, is it documented somewhere? Recent discussion in this forum suggests that I can’t set breakpoints with compiled mode, which makes it seem not useful for debugging.
Correct, it just turns on Julia’s normal execution mode, and that doesn’t allow breakpointing. Keep in mind that this kind of happens automatically in lanuages like Matlab & Python: much of the functionality is written in C internals, and you can’t step into that code either. In Julia you can step into everything, but the downside is that you’re much more dependent on interpreter speed.
The options I know about are (1) to use smaller problems where the computational load will not be so high, (2) use alternative forms of debugging like Infiltrator or @show/@showln macros, (3) live with the slowness, or (4) contribute to JuliaInterpreter and help make it faster.
Would things be any different in Juno? I only stopped using it recently because all the windows disappeared and that seemed like a sign to go with the flow to VSCode. I don’t recall Juno being so slow in debugging, and I assume the “no windows” problem is fixable.
Alternately, I could try smaller data structures to test my theory that somehow preparing to display them, even if I don’t display them, is the source of the slowdown.
There’s a bit of a footgun here though: If you use the VSCode debugger by any other means than the supplied @run/@enter macros we will start a new process for you, which has a constant overhead of a couple of seconds.
I am using VSC for AL development (Microsoft Dynamics 365 Business Central), where I have issues that debugger gets super slow when I have any parameter added in the Watcher window. As I close (hide) the Watcher window with parameters not removed, it works as expected - jump from line to line using F11 (step into) works as expected.