# Debugging extremely slow
**URL:** https://discourse.julialang.org/t/debugging-extremely-slow/53801
**Category:** Tooling
**Tags:** question
**Created:** [January 22, 2021, 7:18pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801 "2021-01-22T19:18:00Z")
**Posts on this page:** 17
**Page:** 3
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [June 5, 2023, 4:23pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/42 "2023-06-05T16:23:05Z")
> Or is the second line not needed given that the third line will be executed?
Correct
> How does this compare with clicking on the + sign in the Run and Debug area of VSCode and adding MyPackage?
I think that they are identical (meaning that VS Code executes that `push!` command internally). One of the VS Code devs might be able to comment on what happens if it does have internal modules (I don’t know what happens in that case).
---
### Author:  [@Soldalma](https://discourse.julialang.org/u/Soldalma)
#### Post date: [June 5, 2023, 11:15pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/43 "2023-06-05T23:15:21Z")
I tried a variety of strategies to make debugged code run faster. The bottom line is that adding my own packages to the list of compiled packages in VSCode works quite well, but the code you suggested does not seem to work in my system. Here is what I did:
1. Commented or uncommented all commands referring to Revise.jl.
2. Always imported MyPackage1, MyPackage2, MyPackage3, and MyPackage4. These are packages I created.
3. Further down in the code I always imported these two packages:
using MethodAnalysis
import JuliaInterpreter
4. Further down I inserted these lines in my code and in some cases commented them out:
```julia
union!(JuliaInterpreter.compiled_modules, child_modules(Base))
push!(JuliaInterpreter.compiled_modules, MyPackage1)
push!(JuliaInterpreter.compiled_modules, MyPackage2)
push!(JuliaInterpreter.compiled_modules, MyPackage3)
push!(JuliaInterpreter.compiled_modules, MyPackage4)
```
1. Copied the last section of my code, called Backtest, and pasted it at the end of the code so that that section would run twice. This was to evaluate the effect of compilation on execution speed. So I have Backtest1 and Backtest2, which runs faster.
2. Ran the program under several combinations of:
a) Pressing F5 (debugging) or Ctrl+F5 (not debugging).
b) Using Revise.jl or not (see 1) above)
c) Three alternatives:
i) Using the + sign in the Run and Debug section on the right-hand pane of VSCode to add my packages to the list of compiled packages, and commenting out the code in 4) above (Compiled forced by VSCode),
ii) using the code in 4) above and removing my packages from list of compiled packages in the Run and Debug section (Compiled forced by code),
iii) commenting out the code in 4) above and removing my packages from the list of compiled packages on the Run and Debug section (Not compiled),
ii) using the code in 4) above and adding my packages to the list of compiled packages in the Run and Debug section (Compiled forced by code),
The following table contains the results.
From the last two lines one can see that the code in 4) above did not have any effect. What did I do wrong?
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [June 6, 2023, 9:28am UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/44 "2023-06-06T09:28:08Z")
If you’re using VS Code rather than the command-line Debugger.jl, it’s possible that VS Code is using an internal vendored copy of JuliaInterpreter and so the manual commands I described won’t work. (In essence there may be two JuliaInterpreters and my commands add the packages to the wrong one.) Adding packages via VS Code’s GUI must be doing exactly the same thing internally so I don’t think you have to worry that you’re missing out on something.
---
### Author:  [@gmantegna](https://discourse.julialang.org/u/gmantegna)
#### Post date: [June 26, 2023, 11:36pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/45 "2023-06-26T23:36:02Z")
Thanks so much for your continued help here Tim. I am using VSCode so it is difficult to explicitly run things in the same REPL as the debugger. As a result I’m having a hard time figuring out how to add Base to the compiled modules in my situation. (Where would I run the push! code you sent?) Additionally, I want to basically always use the debugger in this Matlab-like way so am looking for a way to turn on this behavior by default. Any tips?
---
### Author:  [@gmantegna](https://discourse.julialang.org/u/gmantegna)
#### Post date: [June 26, 2023, 11:37pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/46 "2023-06-26T23:37:31Z")
Although I just saw your last message in this thread. So I guess it is a losing battle. But would be great to figure out if there was a way to use the VSCode debugger in the Matlab-like way. I think it would really enhance the user experience for a lot of people.
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [June 27, 2023, 11:57am UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/47 "2023-06-27T11:57:34Z")
@pfitzseb @davidanthoff any tips?
---
### Author:  [@pfitzseb](https://discourse.julialang.org/u/pfitzseb)
#### Post date: [June 27, 2023, 12:01pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/48 "2023-06-27T12:01:32Z")
Take a look at the `Julia: Compiled Code` section in the VS Code debugger pane:
It allows you to set modules or functions as compiled/interpreted, which has the exact same effect as the function calls Tim outlined above.
---
### Author:  [@gmantegna](https://discourse.julialang.org/u/gmantegna)
#### Post date: [June 27, 2023, 8:20pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/49 "2023-06-27T20:20:15Z")
> [@tim.holy](#):
>
> @pfitzseb
Amazing, thank you so much!!
---
### Author:  [@mariusd](https://discourse.julialang.org/u/mariusd)
#### Post date: [August 27, 2023, 9:10pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/50 "2023-08-27T21:10:27Z")
@Soldalma, @fmvin, @gmantegna
I have created a documentation on how to speed-up the debugger in vscode.
[settings-to-speed-up-the-debugger](https://www.julia-vscode.org/docs/dev/userguide/debugging/#Settings-to-speed-up-the-debugger)
It’s a combination of:
- _ALL\_MODULES\_EXCEPT\_MAIN_
- using system images
- debugging in the REPL mode [Debugging-code-from-the-REPL (julia-vscode.org)](https://www.julia-vscode.org/docs/stable/userguide/debugging/#Debugging-code-from-the-REPL)
See the documented [example-for-faster-debugging](https://www.julia-vscode.org/docs/dev/userguide/debugging/#Example-for-fast(er)-debugging)
While I show how to set `packages/modules` as compiled in `settings.json`, you can also add individual functions there, e.g. `Main.SomeModule.somefun`.
---
### Author:  [@mariusd](https://discourse.julialang.org/u/mariusd)
#### Post date: [September 4, 2023, 1:13pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/52 "2023-09-04T13:13:13Z")
> [@tim.holy](#):
>
> ```julia
> using JuliaInterpeter, MethodAnalysis
> union!(JuliaInterpreter.compiled_modules, child_modules(Base))
>
> ```
@tim.holy How can we `push!` all modules and submodules except _Main_, with this approach? Usually we only debug _Main_.
Why is this needed? We use additional packages beside `Base`, let’s say `GLMakie` for plotting. And `GLMakie` installs a plethora of other packages as dependencies, and we obviously don’t want to `push!` them manually into the interpreter.
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [September 4, 2023, 1:21pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/53 "2023-09-04T13:21:00Z")
> How can we `push!` all modules and submodules except _Main_, with this approach? Usually we only debug _Main_.
```julia
union!(JuliaInterpreter.compiled_modules, setdiff(Base.loaded_modules_array(), Main))
```
> Why is this needed?
What do you do if you want to step into a function defined in another package? Once you get into compiled mode, stepping in and breakpoints are no longer supported.
---
### Author:  [@mariusd](https://discourse.julialang.org/u/mariusd)
#### Post date: [September 4, 2023, 3:33pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/54 "2023-09-04T15:33:46Z")
> [@tim.holy](#):
>
> What do you do if you want to step into a function defined in another package? Once you get into compiled mode, stepping in and breakpoints are no longer supported.
Usually I don’t. If someone wants to do debug `SomePackage` for whatever reason, he simply has to
```julia
using SomePackage
union!(JuliaInterpreter.compiled_modules, setdiff(Base.loaded_modules_array(), [Main, SomePackage]))
```
Note your code has to be adjusted a bit: `union!(JuliaInterpreter.compiled_modules, setdiff(Base.loaded_modules_array(), [Main]))`
Question:
Beside `Base.loaded_modules_array()`, do we also need to step in each loaded module with `child_modules(...)`?
---
### Author:  [@tim.holy](https://discourse.julialang.org/u/tim.holy)
#### Post date: [September 4, 2023, 7:18pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/55 "2023-09-04T19:18:02Z")
> Usually I don’t.
Fair enough. But usually I do. I’m not sure what the default should be, but for a user who hasn’t read the documentation carefully and got bit one way or another, one has to choose between the lesser of two evils:
- “Julia’s debugger can’t step into any function not defined in `Main`!”
- “Julia’s debugger is slow!”
To me the second is not nearly as bad as the first. And if someday we improve the performance of the debugger, we might regret it if we had gone with the first.
> Question:mBeside `Base.loaded_modules_array()`, do we also need to step in each loaded module with `child_modules(...)`?
Yes, if you want to be completely comprehensive. I’d be comfortable with merging a pull request to JuliaInterpreter that makes all this easier.
---
### Author:  [@mariusd](https://discourse.julialang.org/u/mariusd)
#### Post date: [September 4, 2023, 7:51pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/56 "2023-09-04T19:51:53Z")
Debugging in Julia is just decent for the code I have tested. The problem is rather we don’t document all the features we provide, and some of them are essential. This must be improved, because we end-up spending more time guiding users in forums than creating a complete documentation.
Imagine a new user who wants to debug. He starts here: [Debugging · Julia in VS Code (julia-vscode.org)](https://www.julia-vscode.org/docs/dev/userguide/debugging/). They need to imediatelly know all available configs for debbuging and all external tools like Debugger.jl and Infiltrator.jl.
Here is a modest PR in this regard: [Minimally document externall debugging tools by MariusDrulea · Pull Request #77 · julia-vscode/docs (github.com)](https://github.com/julia-vscode/docs/pull/77).
Improving the docs menu will help as well: [Include headings level 3 in the menu, on click · Issue #75 · julia-vscode/docs (github.com)](https://github.com/julia-vscode/docs/issues/75)
---
### Author:  [@mariusd](https://discourse.julialang.org/u/mariusd)
#### Post date: [September 4, 2023, 8:16pm UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/57 "2023-09-04T20:16:11Z")
> [@tim.holy](#):
>
> Yes, if you want to be completely comprehensive. I’d be comfortable with merging a pull request to JuliaInterpreter that makes all this easier.
There shall be 2 PR. One in JuliaInterpreter and another one to show the users how to use this feature [Debugging](https://www.julia-vscode.org/docs/dev/userguide/debugging/).
> [@tim.holy](#):
>
> To me the second is not nearly as bad as the first. And if someday we improve the performance of the debugger, we might regret it if we had gone with the first.
Don’t worry, we want to debug other modules than _Main_, like calling `map(my_fun, some_array)`. For now, at least most of _Main_ shall be easily debug-able.
---
### Author:  [@davidanthoff](https://discourse.julialang.org/u/davidanthoff)
#### Post date: [September 5, 2023, 6:30am UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/58 "2023-09-05T06:30:24Z")
> [@mariusd](#):
>
> They need to imediatelly know all available configs for debbuging and all external tools like Debugger.jl and Infiltrator.jl
I’m not sure that is so. Debugger.jl is simply an alternative to the VS Code debugging UI. If one is using the VS Code UI, I don’t really think one needs to know about or use Debugger.jl at all (and vice versa). Infiltrator.jl strikes me as useful, but also a bit more advanced.
---
### Author:  [@mariusd](https://discourse.julialang.org/u/mariusd)
#### Post date: [September 5, 2023, 7:48am UTC](https://discourse.julialang.org/t/debugging-extremely-slow/53801/59 "2023-09-05T07:48:11Z")
To be honest, I am not entirely satisfied with the current UI debugging option, see my experience here [Documentation for fast debugging by MariusDrulea · Pull Request #74 · julia-vscode/docs (github.com)](https://github.com/julia-vscode/docs/pull/74). I do prefer to use the _settings.json_ to set up the compiled/interpreted modules, just like in the PR. Equivalently, other users might prefer to set-up the compiled modules in the code, by pushing them to JuliaInterpreter list of compiled modules. And I might also go this route in the future.
[Previous page](https://discourse.julialang.org/t/debugging-extremely-slow/53801.md?page=2)