Pluto notebook in Julia v1.7.3 vs v1.8.0

General Usage
1

I have a relatively small Pluto notebook. It uses the following packages:

using PlotlyBase, HypertextLiteral, PlutoUI
using Symbolics:@variables
using LinearAlgebra, NLsolve
using Dates, PeriodicalDates 
using DataFrames, CSV
import PlotlyJS: savefig

If I run it with Julia 1.7.3 it will take 110 seconds. However, if I run the same notebook on the same machine, with precisely the same packages, with Julia 1.8.0 it takes 136 seconds.

I am on a Windows machine, and all packages are up to date. Is this an expected outcome, or should I do something else to avoid this slower performance? Usually, larger Pluto notebooks take quite a while to run, and in this case, v1.8.0 is almost 25% slower than v1.7.3.

Package compilation takes 16.8 s in v1.7.3 and 26.6s in v1.8.0.

Thanks

3

Given the reactive nature of Pluto notebooks, it does not make much sense to compare the second run. In the second run, the entire notebook immediately emerges in both Julia versions.

Nevertheless, considering the typical uses of Pluto notebooks, I would not be very “polite” to ask, e.g., students, to run the notebook a second time because it will be terribly fast.

4

I don’t think that @digital_carver was suggesting that you have users run the notebook twice, but trying to hypothesize about the source of the change in runtime between versions. It is a reasonable theory, I think. I agree it’s not great to slow start up times for notebooks, but this precompilation means that if someone opens the notebook again, it should startup faster than before.

If this is not true, then there might be another cause to investigate.

2 Likes
5

Sorry, my second paragraph above was poorly written. I did not mean to say that @digital_carver was rude to me. In fact, he was trying to help. I was putting myself in the position of asking a student to run the same notebook a second time. That would be rude (and nonsensical).

The post above has been edited. Sorry.

1 Like
6

The amount that can be precompiled has greatly increased in 1.8 compared to 1.7, see e.g. Improvements in package precompilation | Tim Holy & Valentin Churavy | JuliaCon 2022 - YouTube . Because Pluto runs each notebook in its own environment, you more or less pay that precompilation cost each time you start the notebook. (There is some fine print about the precompilation cache here.) The short example here that has a lot of “big” packages highlights this. However, if you look at the first call to do meaningful work after the setup cell, it will probably be faster on 1.8, which does matter a lot for reactive notebooks.

1 Like