# Should we distribute multiple official system images for Julia 1.11?

**URL:** <https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353>\
**Category:** Internals & Design\
**Tags:** repl, pkg, system-image\
**Created:** [December 9, 2023, 10:43am UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353 "2023-12-09T10:43:24Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [December 9, 2023, 10:43am UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/1 "2023-12-09T10:43:24Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [December 9, 2023, 10:50am UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/2 "2023-12-09T10:50:43Z")

</div>

> [@mkitti](#):
>
> To solve this, I propose that we distribute a distinct “interactive system image”.

Good idea!

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [December 9, 2023, 11:11am UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/3 "2023-12-09T11:11:04Z")

</div>

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:

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

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

```

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

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

```

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

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

```

```julia
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:

```julia
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:

```julia
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.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [December 9, 2023, 11:55am UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/4 "2023-12-09T11:55:13Z")

</div>

To add some context, I’m currently working on [splitting the Pkg.REPLMode module into an extension package](https://github.com/JuliaLang/Pkg.jl/pull/3724). 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`](https://github.com/fredrikekre/jlpkg) and have that command line driver use a different system image.

---

<div class="post-metadata">

**Author:** ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)\
**Post date:** [December 9, 2023, 11:59am UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/5 "2023-12-09T11:59:18Z")

</div>

> [@mkitti](#):
>
> Perhaps I can call it “Time To First `] status`”.

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

---

<div class="post-metadata">

**Author:** ![sob](https://avatars.discourse-cdn.com/v4/letter/s/65b543/32.png) [@sob](https://discourse.julialang.org/u/sob)\
**Post date:** [December 9, 2023, 12:01pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/6 "2023-12-09T12:01:22Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [December 9, 2023, 12:04pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/7 "2023-12-09T12:04:02Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [December 9, 2023, 12:32pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/8 "2023-12-09T12:32:47Z")

</div>

> [@mkitti](#):
>
> 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`”.

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.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [December 9, 2023, 12:39pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/9 "2023-12-09T12:39:18Z")

</div>

> [@Mason](#):
>
> 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](https://juliahub.com/ui/Packages/PrecompileTools) or equivalent.

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.

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

```

> <https://github.com/JuliaLang/julia/pull/52249>
>
> \- Move Pkg.BinaryPlatforms compatibility shim to Base.BinaryPlatforms.PkgCompat
> …
> \- Move UnstableIO from Pkg.jl to Base
> 
> Address Pkg.jl invalidations by moving code to Base
> https://github.com/JuliaLang/Pkg.jl/issues/3702

> <https://github.com/JuliaLang/Pkg.jl/pull/3712>
>
> \- Move Pkg.BinaryPlatforms to Base.BinaryPlatforms.PkgCompat
> \- Move UnstableIO …to Base
> 
> Corresponding Julia PR (merge this first):
> https://github.com/JuliaLang/julia/pull/52249
> 
> Fix #3702 . No more invalidations.
> 
> \`\`\`julia
> julia\> using SnoopCompileCore
> 
> julia\> invalidations = @snoopr begin
> using Pkg
> Pkg.activate()
> end
> Activating project at \`~/.julia/environments/v1.11\`
> 2-element Vector{Any}:
> MethodInstance for Base.typeinfo\_implicit(::Any)
> "invalidate\_mt\_cache"
> 
> julia\> using SnoopCompile
> Precompiling SnoopCompile
> 4 dependencies successfully precompiled in 78 seconds. 58 already precompiled.
> \[Info: Precompiling SnoopCompile \[aa65fe97-06da-5843-b5b1-d5d13cad87d2\]
> 
> julia\> trees = invalidation\_trees(invalidations)
> SnoopCompile.MethodInvalidations\[\]
> \`\`\`

> <https://github.com/JuliaLang/Pkg.jl/pull/3711>
>
> Adds some precompilation for Pkg.REPLMode.repl\_init
> 
> Removes direct reference to… Base.active\_repl
> 
> Add Base.Experimental.@force\_compile

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

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [December 9, 2023, 12:45pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/10 "2023-12-09T12:45:07Z")

</div>

> [@mkitti](#):
>
> I’m not quite sure we can use [PrecompileTools.jl](https://juliahub.com/ui/Packages/PrecompileTools) here yet unless we also make it a “default” package.

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

> [@mkitti](#):
>
> My concern here is that I’m not sure if any of these efforts actually address the user interface issue I’m talking about.

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.

---

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [December 9, 2023, 1:01pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/11 "2023-12-09T13:01:10Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [December 9, 2023, 1:04pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/12 "2023-12-09T13:04:10Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![cserteGT3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/csertegt3/32/8283_2.png) [@cserteGT3](https://discourse.julialang.org/u/cserteGT3)\
**Post date:** [December 9, 2023, 1:39pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/13 "2023-12-09T13:39:54Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [December 9, 2023, 1:49pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/14 "2023-12-09T13:49:00Z")

</div>

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,

```plaintext
$ 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.

---

<div class="post-metadata">

**Author:** ![mkitti](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkitti/32/12459_2.png) [@mkitti](https://discourse.julialang.org/u/mkitti)\
**Post date:** [December 9, 2023, 2:07pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/15 "2023-12-09T14:07:21Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Mason](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mason/32/2423_2.png) [@Mason](https://discourse.julialang.org/u/Mason)\
**Post date:** [December 9, 2023, 2:07pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/16 "2023-12-09T14:07:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [December 9, 2023, 2:12pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/17 "2023-12-09T14:12:40Z")

</div>

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

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

---

<div class="post-metadata">

**Author:** ![joa-quim](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/joa-quim/32/227_2.png) [@joa-quim](https://discourse.julialang.org/u/joa-quim)\
**Post date:** [December 9, 2023, 2:16pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/18 "2023-12-09T14:16:08Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ufechner7](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ufechner7/32/51363_2.png) [@ufechner7](https://discourse.julialang.org/u/ufechner7)\
**Post date:** [December 9, 2023, 2:18pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/19 "2023-12-09T14:18:40Z")

</div>

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](https://global.discourse-cdn.com/julialang/original/3X/a/d/ad79588087278c512777cdf5ed4ea4f01b230d74.png)  
you can see in grey what WOULD be completed if you type \<TAB\>…

---

<div class="post-metadata">

**Author:** ![rveltz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/rveltz/32/2707_2.png) [@rveltz](https://discourse.julialang.org/u/rveltz)\
**Post date:** [December 9, 2023, 2:29pm UTC](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353/20 "2023-12-09T14:29:26Z")

</div>

how do you install 1.11?

[Next page](https://discourse.julialang.org/t/should-we-distribute-multiple-official-system-images-for-julia-1-11/107353.md?page=2)