Debugger sluggish with high-iteration comprehensions

[BioTurboNick]

Please search existing issues to avoid duplicates.

Details

• Atom version: 1.35.1
• Julia version: 1.1.0
• OS: Win10 x64
• Package versions:
  • Atom.jl: 0.8.3
  • julia-client: 0.8.2
  • ink: 0.10.2

Steps to reproduce

@Enter into a function containing this array comprehension and then step over it:

nlocalmolecules = 3;
radius = 400;
iterations = 10000;
randomcoordinates1 = [randomcoordinates2d(nlocalmolecules1, radius) for i ∈ 1:iterations]

where

function randomcoordinates2d(count, radius)
    angles = rand(count) * τ # from Tau.jl
    radii = sqrt.(rand(count) .* (radius ^ 2)) # required for a uniform distribution around the circle
    x = radii .* cos.(angles)
    y = radii .* sin.(angles)
    z = zeros(count)
    return [x'; y'; z']
end

The code executes correctly and quickly outside the debugging context. In the debugging context, it is saturating my CPU and doesn't end. If I reduce the iteration count to 10, it works relatively quickly.

If there isn't an easy way to speed this up, would one idea be to add a button to process the next line without debugging?

It'd be even more helpful to break execution without losing the workspace, but that's probably a bigger issue?

[timholy]

Make yourself a nice cup of tea and start reading the performance musings:

• Compiled frames: a sketch JuliaDebug/JuliaInterpreter.jl#204
• Performance opportunities JuliaDebug/JuliaInterpreter.jl#206

This is only the tip of the iceberg; there's already been merged a lot of performance-focused work to get to where it is now (certain methods are 1000x faster than they were two weeks ago). Unfortunately, the next big gains are going to be more difficult.

[BioTurboNick]

Thanks :-) I did notice it was quite a bit snappier.

[KristofferC]

How is this a bug?

[BioTurboNick]

It basically prevents debugging of code that normally executes quickly. Indistinguishable from a hang and forces user to terminate the Julia session and start over, then spend hours trying to figure out why it wasn't working so that they can continue debugging.

[KristofferC]

Ok, so not a bug then but a doc issue or a performance issue.

[BioTurboNick]

In the sense of works as designed and formally correctly? Sure, not a bug.

If the OS takes an exceptionally long time to do something that causes a user to reboot the OS and lose their unsaved work, I think that would be considered a bug, even if it was formally working as designed.

[KristofferC]

causes a user to reboot the OS and lose their unsaved work

Why would you reboot the OS without saving your work because a computation takes a long time? Not sure we can protect against that.

[BioTurboNick]

I'm talking about a hang that prevents you from doing anything else on the OS.

[KristofferC]

Interesting. A Ctrl-C interrupts it immediately for me. Can you reproduce it? Looking at the RAM it was using ~250 MB so that shouldn't cause the system to swap.

[BioTurboNick]

That does work, thanks. I'd gotten used to it doing nothing when Julia runs into trouble usually.