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

Aberta
  • Algo errado?
#373 1 comentário 0 reações 1 responsável Ver no GitHub

Mantenedores costumam responder em até 1 dia

@ocots já está trabalhando nisso.

Desde 5/11/2026.

Avaliação

Esta issue ainda não foi avaliada.

Descrição

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

Linguagem predominante
Julia
Estrelas
13
Forks
1
Merge médio
3h 20min
PRs com merge (30d)
27

Preparar o ambiente

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de control-toolbox/OptimalControlProblems.jl

Todas as issues de control-toolbox/OptimalControlProblems.jl

Issues semelhantes

Mais issues de Julia

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.