[singularity2001]

"Together with PrecompileTools.jl, Julia 1.9 delivers many of the benefits of PackageCompiler without the need for user-customization."

does it mean I still have to invoke special workflows and commands to get compilation benefits or does it work out of the box for normal julia invocations?

[jakobnissen]

PrecompileTools works out of the box - in the sense that the package developer needs to add a "@compile_workload" block in their package, but the users don't need to do anything. There is no special workflow or command to use it.

The tradeoffs are somewhat larger load times (TTL), increased precompilation time (because some of the compilation moves to precompile time), and increased disk usage by the package.

[sundarurfriend]

> The tradeoffs are somewhat larger load times (TTL)

The post says "TTL has also been reduced, albeit not as dramatically as TTFX." And the graph seems to indicate the same. Is that not true, or are you comparing it to pre-1.7 TTLs (which are not shown in the post), or is it just context(/project)-dependent?

[jakobnissen]

Both are true. Package images and the use of PrecompileTools makes packages load slightly slower, because there is more data to load, namely all the precompiled machine code. It's still faster to load than to compile, so the gains in TTFX (i.e. compilation) outweighs the gains in TTL (i.e. loading).

For 1.9, code loading has also been optimised, such that code loading is in many cases faster in 1.9 than in 1.7. However, this is an optimisation that is separate from the improvements to precompilation. The developers are currently working on even more TTL optimisations, so I expect that TTL will be significantly reduced in Julia 1.10, but for now, it's nice to see that TTL optimisations present in 1.9 has counteracted the increasing load times from package images.

[ChrisRackauckas]

There's already some pretty nice improvements in TTL in v1.10. I plan to move onto the v1.10 betas once those are cut, since it's not an insignificant difference. A lot of the testing is being done on the test package https://github.com/JuliaComputing/OmniPackage.jl which is a purposefully massive mess of packages. It's a bit difficult to make a direct comparison because there's many different computers benchmarking and it's quite difficult to get that gigantic chunk of packages to be exactly the same versions across multiple Julia versions (since some dependencies bump the Julia minimum and such), but you can get some relative numbers by looking at some of the PRs that mention Omnipackage. In v1.8.5 it took about 100 seconds to load and some GC improvements dropped that to about 50 in v1.9 betas (https://github.com/JuliaLang/julia/pull/49185#issuecomment-1...) back a few months ago, while 3 weeks ago a change reported improving it from 21s -> 17s (https://github.com/JuliaLang/julia/pull/49404, with of course many other changes in the middle, just search Omnipackage in the PRs to see the list). Again, not quite apples to apples but in terms of relative magnitude you can see it has many major improvements. There's also some big pieces that haven't merged, like how code loading can be invalidated which is unnecessary and https://github.com/JuliaLang/julia/pull/49525 can handle that. There's also some ideas for "clumping" invalidation checks to take it down another notch.

So with all of these piling up, I think v1.10 will make a great new LTS since v1.9 feels a bit "4/5 of the way there" because there's still the using time to chop down in the next release to get things to sub-second.

[sundarurfriend]

Thanks, that was a great explanation!

[singularity2001]

Fantastic! so far over 100 packages seem to support it which is a good start:

https://github.com/search?q=%40compile_workload&type=code