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 
Yes, there should be an option to not load revise in the settings.
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.
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.
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?
Hi,
I need your suggestions, I’m new to Julia. Julia LS precompile is almost impossible on my machine. I know my macbook Air is old still Julia loads after 1-2 secs in Terminal (on Archlinux 5.8.8) But in either Atom’s Juno or VSCode the LS takes almost forever to load - after opening a julia file my CPU goes to 100% and even after 5-6 hours nothing would change. I never had such performance problem with any other language.
I just observed this precompiled sysimage anomaly/improvment. Not sure what can be your problem. For me to create a sysimage is about 300 seconds.
For me Julia’s speed is close to unbeatable. On the startup time had some problem before this precompiled sysimage observation. Now with this improvement we with my friends can develop times faster.
Anyway, if this sysimage building doesn’t work for your, you can still use “bare” sysimages downloaded from the julia site, which has startuptime close to zero. (If bare image doesn’t start under 0.5s, then start a new thread, I guess.)
Welcome to the community.
For me VS Code starts in maybe 1 sec. and with my files, then I run a line of code and maybe 2 sec. overhead for the extension to work. This is with no special sysimage (that I know of), but I AM using Julia 1.6-DEV. Both Code and Atom are fast enough for me, and the REPL (no IDE) starts in, 0.7 sec with Revise (version 3). The script for the sysimage (made with PackageCompiler it seems, it’s known to be slow), isn’t really needed I think.