Long start-up times for Julia REPL in VS Code

It takes VS Code about 10 seconds to go from me clicking on “Julia: Start REPL” to the REPL being up and running. In comparison, starting Julia in a terminal takes only one second.

Where does this difference come from? Is there a way to speed up the VS Code REPL start-up, perhaps by disabling some rarely used features? For example, it seems that the VS Code REPL loads Revise.jl, which I’m not using at the moment. Can I disable Revise in return for faster start-up times?

We have to load a fair amount of code at startup. It should have gotten better lately because we now precompile things, but maybe it is still too slow… We could probably try to the kind of things that @tim.holy has done for a number of package recently to speed up things. And hope for improvements in Julia 1.5 :slight_smile:

Yes, there should be an option to not load revise in the settings.

1 Like

One thing in particular that I don’t understand is why the VS Code REPL needs to be (significantly) different from the terminal REPL. I understand that debugging tools like @run and @enter need to be loaded, and also the REPL needs to be set up in such a way that running code snippets from the editor works, but why does this take so long?

That’s mainly because we internally need to load bunch of packages, e.g. JSON for communication between VSCode and Julia, JuliaInterpreter.jl as debugger core, etc.

Thanks to both of you for your answers!

I’d be in favour of giving users the option to trade some features for faster start-up times.

I have a Revise branch that, on Julia 1.6, loads in less than a quarter of the time of the current Revise. However it achieves this partly by delaying some compilation, which it needs to do before its first revision. I’m hoping to have some conversations about the prospect of doing compilation in threads, in which case that branch would become a hands-down win.

6 Likes

Yeah, I think any sort of support for delayed compilation would really help us as well!

Another strategy might be to use a custom sysimage. If there was support to load multiple custom sysimages at startup, things would be super easy for us: we could just compile all the stuff we need into one sysimage and load that at startup, done. We would also never have to worry about conflicts of package versions or anything like that because the extension ships its own private copy of everything it uses.

1 Like

Hey, I find your work really fascinating, thank you!
For me the custom sysimage load time is 4.7-5 second, which is times better but still I just can’t stop to ask.

How can the “base” julia 1.4.2 start instantly(0.1-0.2s)? Isn’t there a way to fit out custom image into the “base” image?