What is the symbol cache of VS Code that Julia needs to download so urgently?

I have an Acer Aspire E11 laptop with an N2840 processor and 2GB DDR3 RAM. It runs Ubuntu 16.04. There are two issues I’ve had when using Julia with VS Code.
Issue 1: As shown in the image below, even when VS Code was not open, Julia was performing a crippling amount of disk I/O (as shown by iotop). I did a ps -aef | grep julia to find this:

navin     3531  1051 18 09:11 ?        00:02:12 /home/navin/julia/bin/julia --startup-file=no --history-file=no --depwarn=no main.jl /home/navin/.julia/environments/v1.7 --debug=no /tmp/vsc-jl-cr-b680fcbe-4e48-4685-a28a-d2622caed0d2  /home/navin/.config/Code/User/globalStorage/julialang.language-julia download https://www.julia-vscode.org/symbolcache --detached=no
navin     3990  3531 64 09:14 ?        00:05:45 /home/navin/julia/bin/julia --code-coverage=none --startup-file=no --compiled-modules=no --history-file=no --project=/home/navin/.julia/environments/v1.7 /home/navin/.vscode/extensions/julialang.language-julia-1.7.5/scripts/packages/SymbolServer/src/server.jl /home/navin/.config/Code/User/globalStorage/julialang.language-julia/symbolstorev5 /tmp/vscjlsymserv-11ea087d-692d

May I know what this SymbolServer download is, why it’s necessary and how I could disable it? Moreover, I don’t understand how and why it is running even when VS Code is not running.

Issue 2: When I run even a simple program in VS Code, it takes around 3 or 4 minutes until the program executes (when run the first time). However, if I run a Julia program from the Bash terminal, it does the compilation and executes earlier (when run the first time) than when run from VS Code. There’s obviously some extra overhead being caused due to the VS Code extension.

Here are the docs for SymbolServer:

https://www.julia-vscode.org/SymbolServer.jl/dev/

If I recall correctly, the VSCode Julia extension used to index all packages in an environment locally to get relevant names for autocomplete etc, SymbolServer allows this to be done once in a remote machine from which the result of that indexing is then distributed.

As for startup latency, 3 to 4 minutes sounds extreme but then 2GB DDR3 RAM is very little to run a modern resource hungry editor like VSCode so maybe it’s not that surprising.

That’s nice. So I guess I just need a more powerful computer to use Julia. Although one thing that had puzzled me was that the process was working even after VS Code was closed. And it was taking up quite a lot of hard disk time. That shouldn’t happen.

You need a powerful computer to use VSCode. You can use Julia without that. Personally I find VSCode too memory-hungry, so I use sublime text instead

4 Likes

I think that’s expected though - my understanding is that when you first start VSCode with the Julia extension, it spins up a separate process to download the symbol cache to not interfere with whatever you’re trying to do in the main process. That separate process can continue running afterwards so that the cache is complete when you start up the next time.

1 Like

That’s not supposed to happen. We should never leave processes hanging, but had issues with that in the past.

I agree with pfitzseb. The process should get killed or safely terminated when VS Code is closed.
@jishnub: I tried Sublime Text just now, but it was annoyingly unintuitive to use. For every single thing, I had to do a Google search for “how to do xyz in SublimeText”, and often, the solutions didn’t work either. I’m surprised that the creator is charging a license fee for such an IDE. Atom is being sunsetted, so that leaves very few options for finding a good IDE that can run Julia, Python and R. I wish Netbeans kept up in the IDE race. It was really good.

You can probably try using VS code without the Julia extension if that is causing the issues (obviously not ideal). You should still have some basic syntax highlighting without it and open up Julia in the terminal to search for the help documentation.

Another possible option for you is using a remote machine for your development. As long as you can ssh into it, you can use VS code to edit files and use any extensions as if it were your own machine. This uses fewer resources on your end so your 2GB of RAM is likely to be enough. The extension for this is Developing on Remote Machines using SSH and Visual Studio Code. If you have (or can get) a more powerful desktop machine but want to use your laptop this can work too.

1 Like