Why does Pluto instantiate each time a notebook is launched?

Hi all,

I’m a bit confused about how Pluto works. As shown in the screenshot below, I noticed that it instantiates each time I launch the same notebook (with no explicit changes to the dependencies). Instantiation accounts for the largest portion of launch time. I don’t think code outside of Pluto works this way.

I assumed that this only happened once following a change in the dependencies. I looked at this thread, but its still unclear to me. Why does it instantiate each time, and is this necessary?

Hi Chris,

Didn’t see a reply, FWIW, this is my understanding:

This happens when 1) you run a notebook for the first time on Pluto or 2) if you have stopped the notebook on the Pluto main page by clicking on the black ‘x’ (1st figure below).

If you restart Pluto itself - “Julia> Pluto.run()” - no notebook is running so every notebook will execute all steps. To prevent this I run Pluto in a separate terminal/Julia process, keep Pluto running as long as possible and stop and restart individual notebooks. The first time after a restart of Pluto I sometimes click a few notebooks I think I will use.

If I make modifications to packages I typically disable Pluto package management by un-commenting the Pkg.activate line (2nd figure below). With Revise active, stopping and starting an individual notebook will then do a partial recompile of the project environment.

My base Julia environment only has Pkg, Revise and Pluto.

Hi Rob. Thanks for confirming and explaining. Do you happen to know why it instantiates each time the notebook is launched? I wonder if it is necessary.

Do you happen to know why it instantiates each time the notebook is launched? I wonder if it is necessary.

In the “default” mode, i.e. package management by Pluto, step 2 (Package management) creates a new project environment for each notebook (Step 1: Workspace setup) which means downloading and instantiating (Step2: Package management) each package in Manifest.toml. Julia also precompiles in step 2.

More (pre-)compilation is needed when executing the block with using … statements, in my example:

StanSample and RegressionAndOtherStories use extensions which are only activated (and compiled) when required. Step 3 (Running code) in the Status display, in this example cell 1, can take a significant amount of time as well.

If you want to share more of what’s done these steps activating a project is your only option. I’m not sure how you can sharethese environments - and thus preventing instantiations - without a new approach to Julia environments.

Given that the choice was made by Pluto in “normal” mode to emphasize on simplicity for (end-)users I can live with it and for day-to-day use I work in project environment when after an initial update of a project (SR2StanPluto.jl) steps 2 and 3 are much faster and shared between SR2StanPluto 30-50 notebooks.

Rob J Goedman
goedman@icloud.com

1 Like

Hey Christopher, thanks for the question!

We instantiate every time to make sure that the packages can be imported (that’s exactly what instantiate does). The question is probably why it is taking a long time every time, since this should be cached, and only take milliseconds when you run a notebook the second time.

Are you using a prerelease of Julia 1.9? In that case, you are probably facing this Pkg bug, which causes instantiation to take a long time, even when everything is already cached: Julia 1.9: adding `Random` causes `TiffImages` to precompile again · Issue #3403 · JuliaLang/Pkg.jl · GitHub

This was fixed by the Pkg developers recently, and it is included in the Julia 1.9.0-rc2 release. So it should be fixed when you update Julia! It will still instantiate every time (otherwise, your packages won’t work!), but it will take less than 100ms if you run the notebook a second time.

4 Likes