[Dev] Precompile the problems so that users and tests do not recompile them every time

Aperta
#373 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@ocots ci sta già lavorando.

Dal 5/11/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Part of #310. Not for now: to do before the collection grows (the roadmap aims at many more problems, #179, #287, #308).

Context

Solving a problem of the OptimalControl modelings costs mostly compilation, and it is specific to each problem: each @def creates its own functions, and the modeler (ADNLP, Exa) and the solver specialize on them. Measured in #360 (phase A, macOS, Julia 1.12): the first pass over the 85 problem × modeling × configuration combinations took 211 s; the eight next passes took 0.1 to 0.2 s each. About 2.5 s per combination, almost all compilation. JuMP models are interpreted and do not pay it (whole JuMP suite: 24 s). This is also why the smoke tests of #363 did not save CPU time: 3 iterations or convergence cost about the same.

At 200 problems × 3 configurations this would be about 25 min of compilation per run (extrapolated, not measured), for the tests and for a user who solves many problems (benchmarks).

Options

  1. Precompilation in the package (PrecompileTools), recommended: a @compile_workload in the extensions OptimalControlModels and OptimalControlScalarizedModels builds each problem and runs a few iterations of the usual configurations. Since Julia 1.9 the native code is stored in the package images in the depot, including the specializations of ADNLP, Exa and the solvers on our functions. A user pays once per install or update; the CI keeps the images in its cache (julia-actions/cache, made reliable by #336 and #340).
    • Drawback: a long install for everyone. A switch is needed, e.g. a preference (Preferences.jl) to precompile all problems (on in the CI and for benchmarks), off or limited to a list by default.
    • Limit: an extension precompiles only for the packages loaded together; the solvers and modelers must be triggers or loaded in the workload.
  2. A system image (PackageCompiler) as a CI artifact: the largest gain at startup, but one image per Manifest, OS and Julia version, rebuilt at every dependency change; CI only.
  3. Less specialization: not realistic, automatic differentiation relies on it.
  4. GPU: CUDA kernels are compiled at run time and are not cached the same way; option 1 does not help much there.

Scope

  • Measure the compilation per problem and configuration, and what a warm cache saves (locally and in the CI).
  • Prototype @compile_workload on a few problems; check the images are reused by a second session and by the next CI run.
  • Decide the default for a user (switch, list, or nothing) and document it.

Done when

  • Measurements: compilation per problem and configuration, cold and warm.
  • A prototype on a few problems, reused across sessions and CI runs, with its install-time cost.
  • A decision on the default for users, documented.

🤖 Generated with Claude Code

Lingua principale
Julia
Stelle
13
Fork
1
Merge medio
3h 20m
PR unite (30g)
27

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di control-toolbox/OptimalControlProblems.jl

Tutte le issue di control-toolbox/OptimalControlProblems.jl

Issue simili

Altre issue su Julia

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.