# First Pluto notebook launches are slower on Julia 1.9 beta 3

**URL:** <https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429>\
**Category:** Internals & Design\
**Tags:** performance, pluto, ttfx\
**Created:** [January 23, 2023, 8:46pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429 "2023-01-23T20:46:06Z")\
**Posts on this page:** 20\
**Page:** 5

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 27, 2023, 7:29pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/81 "2023-01-27T19:29:25Z")

</div>

Oh, another point I’d like to make: The temporary depot created is 0.7GB, which is a lot of complex software that was downloaded, installed and worked flawlessly on many different systems, including multiple different graphics stacks. The experience in so many programming languages trying to get this kind of stuff installed and working is having it take days to get right, if ever. We’re not even talking about _if_ things install anymore—it’s taken as a given! Anyway, a couple of minutes to install a fully working graphics stack is a delight.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 27, 2023, 7:31pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/82 "2023-01-27T19:31:38Z")

</div>

I think the issue is that since Pluto is reactive, there’s an expectation that everything is supposed to be snappy. But installing and loading packages from the internet just isn’t. So the solution seems to me to be to separate the UX for things that are known to be slow and not reactive from the things that are part of the real reactive experience. Get package installation out of the reactive UX!

---

<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:** [January 27, 2023, 7:46pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/83 "2023-01-27T19:46:22Z")

</div>

> [@StefanKarpinski](#):
>
> It seems worth considering how to better separate in Pluto the software installation stage from the software usage stage. Maybe take `using Foo` statements out of the notebook entirely and have a GUI widget on the right where the user manages what packages they want, which can give better feedback on download/install/compile and maybe give some ability to manage what versions are used.

I think this is a pretty clever idea! Have an import form where the user enters packages they want, and there could even be a submenu that shows versions available with an indicator or highlighting for versions which are already installed.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 27, 2023, 8:16pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/84 "2023-01-27T20:16:50Z")

</div>

> [@StefanKarpinski](#):
>
> If you’re not constantly upgrading your packages, that’s overall a big win since that 33% is every time you restart and that 85% is rarely.

Another phrasing is “one-off and ad hoc analysis becomes 85% slower, while running the same script repeatedly becomes 33% faster”.

If that’s the choice, I personally wouldn’t switch to “new pkgimages” in day-to-day use – only for very specific workloads. Lots of work I do in Julia is exploratory analysis, that will only be run a few times. These scenarios hardly gain anything from new pkgimages, and would work better with the pre-1.9 approach.

Best of both worlds for interactive work would be to run “old” precompilation at first, and present a ready to use REPL/notebook immediately after that. Then, run the “new” native code precompilation in background when no user code executes – and save native pkgimages after it completes. Does this sound feasible?

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 27, 2023, 8:27pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/85 "2023-01-27T20:27:02Z")

</div>

I don’t think that’s an accurate phrasing at all. It’s only installation of packages that got slower, which is not what “one-off and ad-hoc analysis” suggests. You can do one-off ad hoc analysis all day with a fixed set of packages installed. In my experience I install new packages pretty infrequently—I have a set of tools that I use and needing a new one isn’t all that common once they usual suspects are available.

---

<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:** [January 27, 2023, 8:35pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/86 "2023-01-27T20:35:19Z")

</div>

> [@StefanKarpinski](#):
>
> It’s only installation of packages that got slower, which is not what “one-off and ad-hoc analysis” suggests. You can do one-off ad hoc analysis all day with a relatively fixed set of packages installed.

Unfortunately though (stop me if I sound like a broken record) for this to be true in Pluto, it’s going to need to be smarter about reusing package versions used in previous notebooks

The problem is basically just that with Plutos automagic package installation and one-off environments, if you have

- one notebook that uses packages A, B, and C which you made on monday
- another using A, B, and D which you made on wednesday
- and a third one using B, D, and C which you made on friday

then there’s a very real possibility that you end up needing precompile each of packages A, B, C, and D two separate times. This isn’t something that’s likely to happen if you just use the global environment, but with Pluto it definitely does happen.

---

<div class="post-metadata">

**Author:** ![aplavin](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/aplavin/32/222056_2.png) [@aplavin](https://discourse.julialang.org/u/aplavin)\
**Post date:** [January 27, 2023, 8:46pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/87 "2023-01-27T20:46:40Z")

</div>

Pluto is just one instance of this, but the issue is more general.

> [@StefanKarpinski](#):
>
> You can do one-off ad hoc analysis all day with a fixed set of packages installed.

Do you mean using a single environment for everything? It goes against common recommendations (that I totally agree with) of using separate envs for each analysis/project.

---

<div class="post-metadata">

**Author:** ![pdeffebach](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/pdeffebach/32/10320_2.png) [@pdeffebach](https://discourse.julialang.org/u/pdeffebach)\
**Post date:** [January 27, 2023, 8:53pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/88 "2023-01-27T20:53:30Z")

</div>

One workflow that might be nice interactively is something like `] activate --copy` which creates a new environment that copies the current Project.toml and Manifest.toml over. That way you don’t have to pay a precompilation price when doing one-off things, but your state is saved if you want to return to it (even if your main environment changes).

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 27, 2023, 9:29pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/89 "2023-01-27T21:29:32Z")

</div>

If I’m doing exploratory analysis, I do use my usual tools in a shared environment. Once there’s something that works I may snapshot that and save it in a project.

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [January 27, 2023, 9:40pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/90 "2023-01-27T21:40:43Z")

</div>

How do you snapshot an environment?

---

<div class="post-metadata">

**Author:** ![visr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/visr/32/17204_2.png) [@visr](https://discourse.julialang.org/u/visr)\
**Post date:** [January 27, 2023, 10:15pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/91 "2023-01-27T22:15:33Z")

</div>

Could Pkg.add perhaps add the latest compatible locally installed version? I want add to add things a.s.a.p., and update can take time to update.

I use separate environments for different scripts, and often use packages with large dependency trees like ModelingToolkit and Makie. When adding these packages to a new environment because I want to quickly try something, I almost always have to wait a long time since usually some of their deps have updated since my last install and it needs to precompile again.

It’s hard for users to think about changing their workflow to avoid more precompilation than they need, but changing Pkg.add behavior would be automatic for everyone. Pkg.status will tell you what is outdated.

---

<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:** [January 27, 2023, 10:32pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/92 "2023-01-27T22:32:54Z")

</div>

I guess I just don’t get why you want to use separate environments for everything if you still want to use all the versions you got from the outer environment. To me this sounds like a request to make `Pkg.add` worse to support a workflow that doesn’t really make sense (to me at least).

---

<div class="post-metadata">

**Author:** ![jar1](https://avatars.discourse-cdn.com/v4/letter/j/c0e974/32.png) [@jar1](https://discourse.julialang.org/u/jar1)\
**Post date:** [January 27, 2023, 10:36pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/93 "2023-01-27T22:36:04Z")

</div>

> [@Workflow for forking an environment](https://discourse.julialang.org/t/workflow-for-forking-an-environment/93660):
>
> I have a “main” environment that has a lot of the packages I use. Whenever I want to try something out, I go to a new directory and I want to use those packages plus a couple of other packages. I don’t want to reinstall these main packages I don’t want to mutate-in-place the main environment with the new packages I want the project’s Project.toml and Manifest.toml to be complete, not relying on some external hidden state Is it possible to get all three of these criteria? If not, how close can…

---

<div class="post-metadata">

**Author:** ![visr](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/visr/32/17204_2.png) [@visr](https://discourse.julialang.org/u/visr)\
**Post date:** [January 27, 2023, 10:42pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/94 "2023-01-27T22:42:19Z")

</div>

I don’t make separate environments for everything, but say if it is a separate project for work, I do.

I don’t know if a Pkg.add that prefers adding already locally available packages is worse. It is faster, and separates updating and adding more clearly. Of course if a package is not available locally it would work as it does now.

---

<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:** [January 27, 2023, 10:56pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/95 "2023-01-27T22:56:33Z")

</div>

> [@lmiq](#):
>
> `Pkg.UPDATED_REGISTRY_THIS_SESSION[] = true`

That, in your startup.jl file, does that. I has been discussed if that should be the default.

---

<div class="post-metadata">

**Author:** ![StefanKarpinski](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stefankarpinski/32/24_2.png) [@StefanKarpinski](https://discourse.julialang.org/u/StefanKarpinski)\
**Post date:** [January 27, 2023, 11:26pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/96 "2023-01-27T23:26:25Z")

</div>

Copy the environment files and then delete things I’m not using in the new copy. At that point I would probably also try updating everything in that environment and make sure it still works.

---

<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:** [January 27, 2023, 11:52pm UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/97 "2023-01-27T23:52:47Z")

</div>

Isn’t the **exact** reproducibility of the environment overrated?

I mean, having it is a nice feature. But don’t we actually expect that updating all non breaking versions still keeps everything working?

Maybe there should be another level of “instantiation”, that adds the latest _available_ non breaking versions of the packages compatible with the project, and just warns the user if updates are available. And if the user updates, other environments sharing the same non breaking versions of packages should benefit automatically from that update, upon this level of “instantiation”.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [January 28, 2023, 12:57am UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/98 "2023-01-28T00:57:52Z")

</div>

> [@lmiq](#):
>
> Isn’t the **exact** reproducibility of the environment overrated?

No.

---

<div class="post-metadata">

**Author:** ![johnh](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/johnh/32/3615_2.png) [@johnh](https://discourse.julialang.org/u/johnh)\
**Post date:** [January 28, 2023, 5:26am UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/99 "2023-01-28T05:26:08Z")

</div>

@StefanKarpinski " We’re not even talking about _if_ things install anymore—it’s taken as a given! Anyway, a couple of minutes to install a fully working graphics stack is a delight."

I suggest having this tattooed on the backside of users of lesser programming languages.

---

<div class="post-metadata">

**Author:** ![carstenbauer](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/carstenbauer/32/4981_2.png) [@carstenbauer](https://discourse.julialang.org/u/carstenbauer)\
**Post date:** [January 28, 2023, 8:04am UTC](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429/100 "2023-01-28T08:04:57Z")

</div>

No, it doesn’t. It only turns off the registry update. This improves things a bit but doesn’t tell the resolver to use package combinations that are already installed and, ideally, precompiled.

BTW, I have this in my startup.jl for a long time.

[Previous page](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429.md?page=4)

[Next page](https://discourse.julialang.org/t/first-pluto-notebook-launches-are-slower-on-julia-1-9-beta-3/93429.md?page=6)