Reduce TTFX with PrecompileTools.jl

[ferrolho]

Following the "State of Julia" talk at JuliaCon 2023, this PR is for adding PrecompileTools.jl as a dependency to TORA.jl and to "exercise" parts of the library during pre-compilation in order to significantly reduce the time to first execution (TTFX) during a regular Julia session. The trade-off for this change is an increased pre-compilation time.

Before

julia> @time using TORA
  5.537528 seconds

julia> using MeshCat

julia> @time robot = TORA.create_robot_franka("panda_arm", Visualizer());
  3.492472 seconds

julia> @time problem = TORA.Problem(robot, 2001, 1/1000);
  14.185131 seconds

julia> @time TORA.fix_joint_velocities!(problem, robot, 1, zeros(robot.n_v));
  0.104086 seconds

After

julia> @time using TORA
  6.968393 seconds

julia> using MeshCat

julia> @time robot = TORA.create_robot_franka("panda_arm", Visualizer());
  0.054041 seconds

julia> @time problem = TORA.Problem(robot, 2001, 1/1000);
  0.040485 seconds

julia> @time TORA.fix_joint_velocities!(problem, robot, 1, zeros(robot.n_v));
  0.004797 seconds

[timholy]

Looks great! No changes needed except to ask if you need to close the plot at the end of the workload; you could test with 1.10beta, which will keep precompilation "open" until all tasks finish. Closing the plot is often all that's needed.

[ferrolho]

Looks great! No changes needed except to ask if you need to close the plot at the end of the workload; you could test with 1.10beta, which will keep precompilation "open" until all tasks finish. Closing the plot is often all that's needed.

Sorry, I didn't fully get that, @timholy. Is it that, since we are plotting within the PrecompileTools.@compile_workload, it is best practice to call Plots.closeall at the end to ensure all plotting windows are closed? At the risk of pre-compilation stalling from Julia v1.10beta onwards, otherwise?

[ferrolho]

One more question: in the before-and-after comparison on my original post above, the TTFX of the methods is way faster, as they have been "exercised" during pre-compilation. However, the actual loading of the package, i.e., using TORA, did not change (it actually increased slightly). Is there anything that can be done about that, or not really?

This slide from the talk is what is throwing me off, because it seems that the TTL is decreasing with newer Julia versions. But maybe that is because of improvements to the core, and not related at all to PrecompileTools.jl?

EDIT

Okay, my bad for not taking the time to properly read PrecompileTools and PackageCompiler.

Task	Julia 1.9 + PrecompileTools	PackageCompiler
Developers can reduce out-of-box TTFX for their users	✔️	❌
Users can reduce TTFX for custom tasks	✔️	✔️
Packages can be updated without rebuilding system image	✔️	❌
Reduces time to load (TTL)	❌	✔️

The short answer seems to be no.

[timholy]

At the risk of pre-compilation stalling from Julia v1.10beta onwards, otherwise?

That's what I am concerned about (you could test with 1.10beta and see if it's actually an issue).

However, the actual loading of the package, i.e., using TORA, did not change (it actually increased slightly). Is there anything that can be done about that, or not really?

Hope for further Julia improvements? I do think there's more we can do to speed loading, although it's a bit complicated. What happened in 1.10 (thanks to others, I've played no real role in TTL) is basically doing a lot of profiling and discovering opportunities for improvement. If you really want to dive into that (warning: there be dragons), read https://docs.julialang.org/en/v1.11-dev/devdocs/external_profilers/#Tracy-Profiler first. That just might discover individual items that are increasing load time. But the alternative is to just wait and see if Julia speeds up loading; it seems like that at least another 2x or more could be attained by some (fairly complicated) architecture changes.

Fundamentally you're loading more code than you were before. Julia 1.9 and 1.10 are faster than their predecessors on the same package implementation, but when you add more code to load then a slowdown is expected. This is a little worse than I would like it to be but it's in the range of what I've seen. You may have to decide between different competing priorities.