julia-vscode

julia-vscode copied to clipboard

If I start VS Code in a particular folder, the Julia extension is extremely slow to respond. I don't even get feedback that I've executed a line of code, and I can wait up to 15 minutes before anything happens. However, if I start VS Code without a folder and instead cd() to the same working directory, the problem goes away.

I would love to get a hint as to what is going on under the hood. I'm guessing that if I open in a folder the Julia extension is attempting to index something that is taking a very long time. However I'm not getting any feedback that it's doing any such thing.

This problem occurs in particular folders, not all folders. At the moment I have 2 folders this occurs in.

I've recorded a side by side video to show the issue. This problem is starting to plague me more and more so I'd love to get some help.

video

This problem occurs in particular folders, not all folders. At the moment I have 2 folders this occurs in.

It's likely that there is some code in these folders for which parsing or static analysis is extremely slow. To help with debugging, you can set the julia.trace.server setting to messages or verbose and then check Output > Julia Language Server trace.

OK, I can see now that the Language Server Trace is indexing the package and is stuck at 0%. Been several minutes now, all I did was open the folder in VS Code and the extension shows this...

[Trace - 9:57:22 AM] Received notification '$/progress'.
Params: {
    "token": "057315fc-0c3c-4ff5-a844-1f68727700e9",
    "value": {
        "kind": "report",
        "message": "Indexing CatapultModel... (0%)"
    }
}

So is there anything I can do? My package is not horribly complex, it's just some models I've generated from ModelingToolkit, there is some code to represent system of equations and jacobians with large sizes (100's of equations), but it's all static straight forward code.

And why does the folder matter? If I open from another location, does the extension then not index the package? Or does it do it in another way?

Only dependencies are indexed, so yes, that package won't be indexed if it's not mentioned in another folder.

That said, the extension is supposed to be responsive even during indexing, so I'm not sure what's going on there.#

Edit: You should also see those specific startup related messages in the status bar.

OK, I spoke too soon. If I open in a different folder (scripts) I get the Indexing message and actually the extension is responsive. If I open in the CatapultModel.jl folder, then I don't get an indexing message. I can't see any other useful information from the Julia Langauge Server Output or trace

Julia Language Server Output (scripts folder, extension is responsive)

[ Info: Starting the Julia Language Server
[ Info: Symbol server store is at 'c:\Users\CarmanBr\AppData\Roaming\Code\User\globalStorage\julialang.language-julia\symbolstorev5'.
[ Info: Starting LS at 1647612980
[ Info: All cache files downloaded. (100%)
[ Info: Indexing CatapultModel... (0%)

Julia Language Server Output (CatapultModel.jl folder, extension not responsive)

[ Info: Starting the Julia Language Server
[ Info: Symbol server store is at 'c:\Users\CarmanBr\AppData\Roaming\Code\User\globalStorage\julialang.language-julia\symbolstorev5'.
[ Info: Starting LS at 1647612697
[ Info: All cache files downloaded.

It's definitely possible that the parser or static analysis are choking on MTK generated models. Any chance you can share the code?

I could potentially share the code directly/personally. Feel free to email directly: brad_carman at instron.com

OK, I have a case (just 7 total files) which includes a file generated from ModelingToolkit which is 20,000 lines. It seems clear that this file is what's causing the slowdown. I can send this to you if you'd like to test it. In this case this file is being included() and I get the slow down with or without opening the folder in VS Code

Hi, is it possible to deactivate parsing or static analysis?

Not without losing most of the extension functionality, at which point you can just disable it.

Thanks for the fast reply.

Mmh, that's a pity since I initially developed my library, other functions, and scripts in Juno, where I hadn't this issue. I guess that I have multiple problems with the folders. Currently, I'm only interested in using the library and scripts, which works fine if it doesn't include folders. So this workaround works for me.

Indexing is really very, very slow. With a project using plots and lots of packages will take 10 minutes it get working. Its a lsp issue. I think working with pluto.jl or repl directly is bettern than vscode for the moment.

I'm also facing the issue of slow indexing when editing certain files, e.g. in OrdinaryDiffEq I have >1 minute wait time or even extension crashes after making a small edit in some files. In these cases, I would like to disable indexing (and as @pfitzseb mentioned, therefore lose most funtionality), but still just keep niceties like ctrl+enter -- can that be done?

Looks like this issue is getting worst as Julia evolve. Open VScode in a specific folder, change the environment to that folder, hit Alt-J-O, terminal responds promptly, and Julia, at the terminal is responsive. But going to any *.jl at that folder, hitting Ctrl-Enter in a line, takes >5 to 6 mins to respond from the moment VScode was opened. After 5 to 6 min, life is normal. Looking at the VScode Output tab (Julia Language Server), I see that Julia internal packages (Statistics and LinearAlgebra are taking > 100s to load, each. Also, LSP/julia/activateenvironment (341.37s since last event). A fragment of the output is shown bellow, attched the complete ouput.

Activating project at c:\Users\ricar\.vscode\extensions\julialang.language-julia-1.76.2\scripts\environments\languageserver\v1.10 [ Info: Starting the Julia Language Server [ Info: Symbol server store is at 'c:\Users\ricar\AppData\Roaming\Code\User\globalStorage\julialang.language-julia\symbolstorev5'. [ Info: Starting LS at 1714762453 [ Info: Downloading cache files... [ Info: Downloading cache files... [ Info: Downloading cache files... [ Info: All cache files downloaded (took 11.0s). [ Info: Package Statistics (10745b16-79ce-11e8-11f9-7d13ad32a3b2) is cached. [ Info: Package SymPy (24249f21-da20-56a4-8eb1-6a02cf4ae2e6) is cached. [ Info: Package LibSerialPort (a05a14c7-6e3b-5ba9-90a2-45558833e1df) is cached. [ Info: Package Roots (f2b01f46-fcfa-551c-844a-d8ac1e96c665) is cached. [ Info: Package ZPlot (6ff8c247-c0f4-4a08-9479-fbcac1bb06ec) is cached. [ Info: Package PlotThemes (ccf2f8ad-2431-5c83-bf29-c5338b663b6a) is cached. [ Info: Package Polynomials (f27b6e38-b328-58d1-80ce-0feddd5e7a45) is cached. [ Info: Package PlotlyJS (f0f68f2c-4968-5e81-91da-67840de0976a) is cached. [ Info: Package PyCall (438e738f-606a-5dbb-bf0a-cddfbfd45ab0) is cached. [ Info: Package FFTW (7a1cc6ca-52ef-59f5-83cd-3a7055c09341) is cached. [ Info: Symbol server indexing took 49.7385404 seconds. [ Info: Loading Statistics from cache... [ Info: Done loading Statistics from cache... (took 120.0s) [ Info: Loading LinearAlgebra from cache... [ Info: Downloading cache files... (0%) [ Info: Downloading cache files... (12%) [ Info: Done loading LinearAlgebra from cache... (took 100.0s) (0%)

..................................

============== Startup timings ============== 0.0 - LS startup started (0.0s since last event) 0.026 - connection established (0.026s since last event) 0.334 - (async) listening to client events (0.308s since last event) 0.574 - (async) listening to symbol server events (0.24s since last event) 0.574 - starting combined listener (0.0s since last event) 3.538 - LSP/initialize (2.964s since last event) 7.109 - LSP/initialized (3.571s since last event) 348.48 - LSP/julia/activateenvironment (341.37s since last event) 348.61 - LSP/textDocument/didOpen (0.125s since last event) 349.06 - LSP/julia/getModuleAt (0.453s since last event) .............................. Any clues? JuliaLanguageServerOutput.zip

No clues here as to what is going on, but just wanted to note that this is probably the same issue as in #3504. In my experience, the server is unresponsive for ~20 minutes.

Can you also share your LS timing output here?

Here are timings from today. The lines that start with LSP/ seem unfamiliar to me - it might be because I was opening and looking through some of my scripts.

LS_timing.txt

Looks like this issue is getting worst as Julia evolve. Open VScode in a specific folder, change the environment to that folder, hit Alt-J-O, terminal responds promptly, and Julia, at the terminal is responsive. But going to any *.jl at that folder, hitting Ctrl-Enter in a line, takes >5 to 6 mins to respond from the moment VScode was opened. After 5 to 6 min, life is normal.

If it's relevant, I experience something similar where attempting to run a .jl script in the REPL simply will not happen with v1.105.2 of the extension. I can execute commands from the REPL: e.g. versioninfo(). But hitting CTRL+Enter takes absolutely forever to send to the REPL. However, if I downgrade back to v1.83.2, then CTRL+Enter works much more quickly as expected.

EDIT: This behavior is w.r.t. Julia v1.10.4 on Windows 11.