# New Julia versions, higher Pluto loading times

**URL:** <https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187>\
**Category:** General Usage\
**Tags:** ttfx\
**Created:** [January 21, 2026, 1:09pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187 "2026-01-21T13:09:38Z")\
**Posts on this page:** 19\
**Page:** 2

<div class="post-metadata">

**Author:** ![mattsignorelli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mattsignorelli/32/221502_2.png) [@mattsignorelli](https://discourse.julialang.org/u/mattsignorelli)\
**Post date:** [January 22, 2026, 2:02pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/21 "2026-01-22T14:02:13Z")

</div>

> [@adienes](#):
>
> if “default Julia” were LTS, that would mean the number of versions to maintain would just be equal to the number of minor versions (currently 14) and grow unbounded over time, which is of course an untenable overhead.

Oops, this is not what I meant… I meant that you would still have the 4 versions you say are actively maintained, but when people install julia they get the _current_ LTS as opposed to the currently-released minor version. Because… stability 🙂

Of course, 1.10 won’t be supported anymore when the LTS is updated to a later minor version. But my point is more that, whatever that minor version is, it ought to be _better_ than 1.10, which in my own personal view means that it does not have the issues that 1.11 and 1.12 have as described here.

---

<div class="post-metadata">

**Author:** ![cuihantao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cuihantao/32/8783_2.png) [@cuihantao](https://discourse.julialang.org/u/cuihantao)\
**Post date:** [January 22, 2026, 2:20pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/22 "2026-01-22T14:20:54Z")

</div>

Edit: just like everyone said, v1.10’s precompilation time is better, but v1.12’s run time performance is better.

---

<div class="post-metadata">

**Author:** ![nilshg](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nilshg/32/2283_2.png) [@nilshg](https://discourse.julialang.org/u/nilshg)\
**Post date:** [January 22, 2026, 2:33pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/23 "2026-01-22T14:33:20Z")

</div>

> [@cuihantao](#):
>
> precompilation and runtime performance

While there have been a number of speculative threads on this, I don’t think anyone has ever shown a genuine _runtime_ regression (or if they have, this was reported as an issue and has been/will be fixed).

(Pre)compilation times are a problem though, which is being tracked in the issue already posted above ([Package precompile time regressions (nightly worse than 1.12 worse than 1.11 worse than 1.10) · Issue #58246 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/58246)).

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [January 22, 2026, 2:54pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/24 "2026-01-22T14:54:40Z")

</div>

> [@nilshg](#):
>
> I don’t think anyone has ever shown a genuine _runtime_ regression (or if they have, this was reported as an issue and has been/will be fixed)

People report specific function calls to package developers, not entire notebooks, and the assumption here is that all dependencies are actively updated. For example, NLsolve.jl 's latest release was in December 2020, when Julia was v1.5.3, and it was [deprecated](https://sciml.ai/news/2024/01/23/nlsolve/) for NonlinearSolve.jl, though its use is still supported in an extension.

---

<div class="post-metadata">

**Author:** ![cuihantao](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cuihantao/32/8783_2.png) [@cuihantao](https://discourse.julialang.org/u/cuihantao)\
**Post date:** [January 22, 2026, 2:55pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/25 "2026-01-22T14:55:36Z")

</div>

You are right. It’s something wrong on my end. I happen to have made some fixes yesterday, and that helped reduce the run time for all versions. I was comparing the previous run time on v1.12 with the now-improved run time in v1.10. To be clear, in my case, v1.12 runs faster than v1.10. Editing my previous post to avoid confusion.

---

<div class="post-metadata">

**Author:** ![fonsp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fonsp/32/222349_2.png) [@fonsp](https://discourse.julialang.org/u/fonsp)\
**Post date:** [January 22, 2026, 3:54pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/26 "2026-01-22T15:54:59Z")

</div>

I agree! Loading times get noticeably slower with each Julia release, and I would recommend sticking to Julia 1.10 for teaching. It’s very frustrating to see this development…

---

<div class="post-metadata">

**Author:** ![VivMendes](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/vivmendes/32/16477_2.png) [@VivMendes](https://discourse.julialang.org/u/VivMendes)\
**Post date:** [January 22, 2026, 11:24pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/27 "2026-01-22T23:24:07Z")

</div>

Just four short points:

1. Defending the claim of no regressions in running times, as some have suggested in this thread, is unpersuasive in the face of substantial evidence to the contrary.
2. The issue may be related to package dependencies; however, based on my observations, NLsolve does not appear to be the particular responsible. Notably, @fonsp’s notebook does not use this package and still exhibits some of the highest regression times I have measured, both during precompilation and at runtime.
3. Sticking to version 1.10 may minimize the current problems in the short term, but it is not a **_competitive_** long-term solution.
4. If the users of the notebooks interact only with their static (HTML) versions, there is no problem at all: any version will do, as long as the notebook’s creator feels happy about loading times (and I do not complain on this side). However, if users have to load and interact with notebooks’ active versions, especially for students, loading times will be prohibitive in the long term.

---

<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 22, 2026, 11:50pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/28 "2026-01-22T23:50:11Z")

</div>

It would be nice to have some command, at least, to test these things cleanly, like `precompile(all=true)` to trigger the precompilation of everything in a project, from scratch. At least we would be able to test many possibilities/causes more clearly.

---

<div class="post-metadata">

**Author:** ![Benny](https://avatars.discourse-cdn.com/v4/letter/b/49beb7/32.png) [@Benny](https://discourse.julialang.org/u/Benny)\
**Post date:** [January 22, 2026, 11:55pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/29 "2026-01-22T23:55:45Z")

</div>

> [@mattsignorelli](#):
>
> We should change the title of this thread, because it is not just a [Pluto.jl](https://juliaregistries.github.io/General/packages/redirect_to_repo/Pluto) problem.

Had a thought that it could be interesting to extract the project and manifest from the notebook and `include` the notebook’s code as a normal .jl file in that environment. If the timings don’t change much, then Pluto and its quirks are probably not factors.

---

<div class="post-metadata">

**Author:** ![cstjean](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cstjean/32/1444_2.png) [@cstjean](https://discourse.julialang.org/u/cstjean)\
**Post date:** [January 23, 2026, 12:48am UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/30 "2026-01-23T00:48:52Z")

</div>

1.12 also has the problem that Ctrl-C kills the Julia session more often than not (at least in my case). Out of curiosity,

_Poll ([view on site](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/30))_

I’m part of the group that upgraded (because up till 1.10 each release was a clear improvement or at least neutral) and now regrets doing so. Not enough to downgrade (that’s a pain), but it’s a daily pang of regret when I accidentally Ctrl-C and kill my session, then it takes 5 minutes to get back up to speed.

---

<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:** [January 23, 2026, 9:49am UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/31 "2026-01-23T09:49:29Z")

</div>

> [@cstjean](#):
>
> the problem that Ctrl-C kills the Julia session

This is actively being worked on, but it will take some time until it is resolved and will probably also require some updates from package authors: [https://github.com/JuliaLang/julia/pull/60281](https://github.com/JuliaLang/julia/pull/60281)

---

<div class="post-metadata">

**Author:** ![RoyiAvital](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/royiavital/32/571_2.png) [@RoyiAvital](https://discourse.julialang.org/u/RoyiAvital)\
**Post date:** [January 23, 2026, 11:23am UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/32 "2026-01-23T11:23:15Z")

</div>

> [@jules](#):
>
> My suspicion is that currently nobody really has a concrete idea why recent Julia versions are slower in many aspects than previous ones. At least, if anybody knows, they have not posted it anywhere I could see it.

That’s intriguing. I assumed it was a design choice which will be fixed later on.

---

<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:** [January 23, 2026, 12:29pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/33 "2026-01-23T12:29:31Z")

</div>

> [@jules](#):
>
> nobody really has a concrete idea

## Potential Causes

Changes like moving `Array` code from C to Julia and stdlib excision from the sysimage contribute to increased compilation work.

So this are concrete ideas. And there is no one-size-fits-all fix. Use `Use --trace-compile-timing` to log compilation durations per method in milliseconds. This command line parameter is available from version 1.12 of Julia.

And then optimize those methods that have a long compilation time.

---

<div class="post-metadata">

**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://discourse.julialang.org/u/jules)\
**Post date:** [January 23, 2026, 12:36pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/34 "2026-01-23T12:36:26Z")

</div>

> [@ufechner7](#):
>
> And then optimize those methods that have a long compilation time.

You can’t counter a precompilation duration increase of almost 100% across the board between 1.10/1.12 by optimizing selected methods, those are fundamental issues. It would be good to see statistics on where exactly that time is spent, which stages of the compiler for example. Maybe it’s more like “death by a thousand cuts” where substantial improvements are very hard to get, or maybe there’s more of a power law thing going on where improvement in a couple key places would already help a lot.

---

<div class="post-metadata">

**Author:** ![hz-xiaxz](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/hz-xiaxz/32/209585_2.png) [@hz-xiaxz](https://discourse.julialang.org/u/hz-xiaxz)\
**Post date:** [January 23, 2026, 4:18pm UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/35 "2026-01-23T16:18:20Z")

</div>

For me `@time using CairoMakie` has a significant boost from 1.11 to 1.12, but that’s another story beyond precompiling.

---

<div class="post-metadata">

**Author:** ![tecosaur](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tecosaur/32/23206_2.png) [@tecosaur](https://discourse.julialang.org/u/tecosaur)\
**Post date:** [January 24, 2026, 6:43am UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/36 "2026-01-24T06:43:11Z")

</div>

One thought this does spark is that (from 1.12+) we might be able to use comparative analysis of `--trace-compile-timing` results on the same code to identify _what sort_ of functions the regressions stem from, and what they’re doing, and from that get a direction to investigate what compiler changes could be related.

---

<div class="post-metadata">

**Author:** ![hisacro](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/hisacro/32/202631_2.png) [@hisacro](https://discourse.julialang.org/u/hisacro)\
**Post date:** [January 26, 2026, 2:32am UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/37 "2026-01-26T02:32:46Z")

</div>

I’m surprised no one mentioned this in the thread, for some unknown reasons I always had the environment loading issues within pluto notebooks. As far as all my pluto notebooks goes, I have defined the local environment to load the packages. For eg.

```julia-auto
begin
	import Pkg
	Pkg.activate("~/.julia/environments/v1.10/Project.toml")
      using ...
end

```

One should try it on the system and see if my claims are valid, but as far from what I saw on different machines, this always had an upper hand because most of the times I invoke Pluto from these Julia versions.

---

<div class="post-metadata">

**Author:** ![j-fu](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/j-fu/32/11373_2.png) [@j-fu](https://discourse.julialang.org/u/j-fu)\
**Post date:** [January 26, 2026, 8:28am UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/38 "2026-01-26T08:28:27Z")

</div>

But this would put all the packages into the global environment, while disabling the Pluto package manager. It would be very hard to share these notebooks with others.  
I mentioned disabling the Pluto package manager [here](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/16) as one possible remedy. The approach I had in mind was like

```julia
begin
  using Pkg
  Pkg.activate(@ __DIR__ )
  using ...
end

```

This allows to put notebooks and `Project.toml` into the same directory and distribute these together e.g. as a git repo. I wrote a bit more on this [here](https://j-fu.github.io/marginalia/julia/project-howto/).

This works for me very well in a shared project situation. In a teaching situation, the Pluto package manager is incredibly helpful with lowering the installation barrier.

---

<div class="post-metadata">

**Author:** ![atthom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/atthom/32/7173_2.png) [@atthom](https://discourse.julialang.org/u/atthom)\
**Post date:** [February 4, 2026, 12:24am UTC](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187/39 "2026-02-04T00:24:27Z")

</div>

I was wondering if you tried the [sysimage](https://julialang.github.io/PackageCompiler.jl/dev/sysimages.html) path?  
Since you’re pretty much loading the same packages years after years, it might be useful for you.  
I don’t know how it integrate with Pluto though.

[Previous page](https://discourse.julialang.org/t/new-julia-versions-higher-pluto-loading-times/135187.md?page=1)