Should we distribute multiple official system images for Julia 1.11?

Internals & Design
, ,
1

In Julia 1.11, REPL.jl and Pkg.jl are now independent packages and not standard in the system image. This will help slim down the system image and make Julia’s packaging more modular. REPL.jl and Pkg.jl will be able to updated independently of a Julia release. I’m also currently investigating how to decouple the two packages by making the Pkg REPL mode a package extension.

However, having Pkg.jl and REPL.jl as independent packages will make startup of the interactive Julia experience slower than it is now where users have come to expect a low latency experience loading the REPL and Pkg REPL mode. While we could tell users to use PackageCompiler.jl to make their own system image including REPL.jl and Pkg.jl, I suspect this may be beyond the capabilities of many who want a low latency experience again.

To solve this, I propose that we distribute a distinct “interactive system image”. This interactive system image may not need to be part of a standard installation, but it should be easily downloadable via the artifacts system. If present, the interactive system image should be loaded when the user starts Julia in interactive mode.

While some of this is technically possible today, additional effort is needed to make this a smoother experience for the end user. The needed innovations are the ability to use a different system image for interactive use than for non-interactive use without having to explicitly provide the system image on the command line, and the ability to distribute and install ahead-of-time compiled system images to a location where can be discovered.

21 Likes
2

Good idea!

3

Keep in mind, it’s a non-trivial amount of extra developer effort, and an extra source of confusion and friction for the new user experience if we start offering a bunch of different sysimages. So I think there needs to be a clear demonstrated need for such thing if we’re going to consider it.

For what it’s worth, here’s what I see on my machine for a few different versions of julia:

shell> time ~/julia-1.8/./julia --startup=no -e "using Pkg, REPL; 1 + 1"

real    0m0.092s
user    0m0.068s
sys     0m0.262s

shell> time ~/julia-1.9/./julia --startup=no -e "using REPL, Pkg; 1 + 1"

real    0m0.081s
user    0m0.054s
sys     0m0.037s

shell> time ~/julia-1.10/./julia --startup=no -e "using REPL, Pkg; 1 + 1"

real    0m0.087s
user    0m0.061s
sys     0m0.034s

shell> time ~/julia-dev/./julia --startup=no -e "using REPL, Pkg; 1 + 1"

real    0m0.469s
user    0m0.454s
sys     0m0.378s

So version 1.11 is current significantly slower than previous versions if you’re loading the REPL and Pkg, but you don’t actually need to load Pkg right away if you just want the REPL:

shell> time ~/julia-dev/./julia --startup=no -e "using REPL; 1 + 1"

real    0m0.194s
user    0m0.180s
sys     0m0.376s

And here’s with no REPL or Pkg:

shell> time ~/julia-dev/./julia --startup=no -e "1 + 1"
real    0m0.065s
user    0m0.046s
sys     0m0.026s

So what we see is that while there is a noticable increase in the startup latency for 1.11 if you want both the REPL and Pkg, it’s still less than half a second, which is pretty reasonable for starting up a REPL.

Julia’s sluggish startup speed is mostly a concern for people who want snappy little scripts that they can run from the shell, and in those scripts they don’t need REPL or Pkg, so I’d expect these changes to make things faster for them.

18 Likes
4

To add some context, I’m currently working on splitting the Pkg.REPLMode module into an extension package. I’m pretty sure this will make the problem slightly worse, although it will have great benefits for little scripts.

It’s difficult to quantify how different the REPL experience feels in Julia 1.11. The place where the experience feels the most off is the latency after hitting ] to enter the Pkg REPL mode. Perhaps I can call it “Time To First ] status”.

Another approach to this would be to use jlpkg and have that command line driver use a different system image.

5

Is that on every session, or precompiled files make it better on subsequent new sessions?

1 Like
6

Speaking only for myself: if using REPL, I’m ok with a 400ms delay at startup (and wouldn’t want to have to worry about 2 different julia installs, one interactive and one not, especially if I was a new user).

I would expect the vast majority of users to need REPL and Pkg when starting also.

18 Likes
7

The lag entering the Pkg REPL mode is every session. You need to load Pkg.jl now. It’s not in the stock system image and it takes somewhere about a half second to load the Pkg pkgimage.

1 Like
8

Sure, but is this something we should care about so much that we should be making the process of choosing and installing a julia version even more complicated and confusing than it already is? I’d say the answer is a resounding no for me personally.

Besides, a lot of the “Time To First ] status” can just be fixed by making Pkg precompile more stuff. It’ll make the time to load a bit slower, but there’s doubtless a ton of room to eliminate the dynamic compilation times using PrecompileTools.jl or equivalent.

The other thing of course is just working on making the Time To Load faster for various operations, and the nice thing about that work is that it’ll have benefits for all packages, not just the REPL and Pkg.

6 Likes
9

I’m not quite sure we can use PrecompileTools.jl here yet unless we also make it a “default” package. That said, I think the following emulates most of that functionality.

    if Base.generating_output()
        Base.Experimental.@force_compile
        # workload
    end

My concern here is that I’m not sure if any of these efforts actually address the user interface issue I’m talking about.

10

That’s why I said “or equivalent” which may include simply writing out precompile directives.

And my concern is that the way you’re proposing we address this would actually end up creating significant new user experience issues, just to save less than a half-second for a functionality that isn’t very latency sensitive.

3 Likes
11

I’m ok with a half second to start the REPL, but I would be disappointed if the first ] status was laggy.

3 Likes
12

Maybe the solution would be to load Pkg.jl eagerly and perhaps asynchronously?

5 Likes
13

From my point of view default julia 1.11 should behave like default julia 1.10. Not being able to use the REPL and Pkg.jl out of the box is a radical change that I would consider a breaking change (and thus should be in 2.0). I would rather see a “classic/default/vanilla” julia and a “slim” version, latter being distributed without REPL and Pkg. This would give users a better perspective: if you understand the difference, you know enough to decide which one is suitable for you. My other point is, that one selling point of julia is the builtin package manager. It would be weird if I’d had to install the builtin package manager separately.

14 Likes
14

If I understand correctly, the REPL and Pkg will still be installed when you install Julia, they just won’t be in the system image. So when you launch Julia from the command line like this,

$ julia

it will start up a REPL session. And the first time you hit ], it will load Pkg.

But maybe someone who knows more can clarify that.

9 Likes
15

Basically Pkg.jl and REPL.jl just become normal packages that just happen to be installed in the default environment by default. Because they are normal packages, they now have normal load times. Like normal packages, they now also have TTFX issues.

5 Likes
16

Yes thar’s correct. The only thing that’s changing is that those packages are no longer bundled into the system image, so loading them has become a bit slower, but the advantage is that the sysimage is now smaller, and startup is faster if you dont load them.

4 Likes
17

Well, if the Pkg TTFX is not resolved, I expect there will be complaints, including from myself. :slight_smile:

Not that it’s the end of the world or anything, but it will feel like a step backwards.

3 Likes
18

The load slowness of 1.11 is certainly related to the sizes of the cache files, which in nightly are ~50% bigger than inn1.10 and compile time > 30% longer.

1 Like
19

Just tried it out. On a fast computer I don’t have any issue with 1.11. Yes, in direct comparison you can see there is a tiny delay after typing st in the package manager mode, but it is less than 0.5 s and can hardly be noticed.

But there is a new auto-completion feature which is cool:

Julia_1.11
Julia_1.11786×533 39.1 KB

you can see in grey what WOULD be completed if you type <TAB>…

10 Likes
20

how do you install 1.11?