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.
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).
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 for NonlinearSolve.jl, though its use is still supported in an extension.
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.
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…
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.
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.
Sticking to version 1.10 may minimize the current problems in the short term, but it is not a competitive long-term solution.
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.
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.
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.
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,
For my usage of Julia, 1.10 is best
For my usage of Julia, 1.11 or 1.12 is best
0voters
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.
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
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.
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.
