diff --git a/docs/src/manual/models.md b/docs/src/manual/models.md index 3262c567665..1b45a1b6375 100644 --- a/docs/src/manual/models.md +++ b/docs/src/manual/models.md @@ -73,44 +73,6 @@ deleting different constraint types, you may need to use [`set_optimizer`](@ref). See [Switching optimizer for the relaxed problem](@ref) for an example of when this is useful. -### Reducing time-to-first-solve latency - -By default, JuMP uses [bridges](@ref LazyBridgeOptimizer) to reformulate the -model you are building into an equivalent model supported by the solver. - -However, if your model is already supported by the solver, bridges add latency -(read [The "time-to-first-solve" issue](@ref)). This is particularly noticeable -for small models. - -To reduce the "time-to-first-solve,s" try passing `add_bridges = false`. -```jldoctest -julia> model = Model(HiGHS.Optimizer; add_bridges = false); -``` -or -```jldoctest -julia> model = Model(); - -julia> set_optimizer(model, HiGHS.Optimizer; add_bridges = false) -``` - -However, be wary. If your model and solver combination needs bridges, an error -will be thrown: -```jldoctest -julia> model = Model(SCS.Optimizer; add_bridges = false); - - -julia> @variable(model, x) -x - -julia> @constraint(model, 2x <= 1) -ERROR: Constraints of type MathOptInterface.ScalarAffineFunction{Float64}-in-MathOptInterface.LessThan{Float64} are not supported by the solver. - -If you expected the solver to support your problem, you may have an error in your formulation. Otherwise, consider using a different solver. - -The list of available solvers, along with the problem types they support, is available at https://jump.dev/JuMP.jl/stable/installation/#Supported-solvers. -[...] -``` - ### Solvers which expect environments Some solvers accept (or require) positional arguments such as a license diff --git a/docs/src/tutorials/getting_started/getting_started_with_julia.jl b/docs/src/tutorials/getting_started/getting_started_with_julia.jl index 34860847518..cd02d57f275 100644 --- a/docs/src/tutorials/getting_started/getting_started_with_julia.jl +++ b/docs/src/tutorials/getting_started/getting_started_with_julia.jl @@ -62,8 +62,7 @@ # ``` # $ julia path/to/file.jl # ``` -# Use the REPL or a notebook instead, and read [The "time-to-first-solve" issue](@ref) -# for more information. +# Use the REPL or a notebook instead. # ### Code blocks in this documentation diff --git a/docs/src/tutorials/getting_started/performance_tips.jl b/docs/src/tutorials/getting_started/performance_tips.jl index 71b97f4050d..d3692261df6 100644 --- a/docs/src/tutorials/getting_started/performance_tips.jl +++ b/docs/src/tutorials/getting_started/performance_tips.jl @@ -34,91 +34,6 @@ import HiGHS # variables. This is particularly important if you're learning JuMP after using # a language like MATLAB. -# ## The "time-to-first-solve" issue - -# Similar to the infamous [time-to-first-plot](https://discourse.julialang.org/t/roadmap-for-a-faster-time-to-first-plot/22956) -# plotting problem, JuMP suffers from time-to-first-solve latency. This latency -# occurs because the first time you call JuMP code in each session, Julia needs -# to compile a lot of code specific to your problem. This issue is actively being -# worked on, but there are a few things you can do to improve things. - -# ### Suggestion 1: don't call JuMP from the command line - -# In other languages, you might be used to a workflow like: -# ``` -# $ julia my_script.jl -# ``` -# This doesn't work for JuMP, because we have to pay the compilation latency -# every time you run the script. Instead, use one of the [suggested workflows](https://docs.julialang.org/en/v1/manual/workflow-tips/) -# from the Julia documentation. - -# ### Suggestion 2: disable bridges if none are being used - -# At present, the majority of the latency problems are caused by JuMP's bridging -# mechanism. If you only use constraints that are natively supported by the -# solver, you can disable bridges by passing `add_bridges = false` to -# [`Model`](@ref). - -model = Model(HiGHS.Optimizer; add_bridges = false) - -# ### Suggestion 3: use PackageCompiler - -# As an example of compilation latency, consider the following linear program -# with two variables and two constraints: - -# ```julia -# using JuMP, HiGHS -# model = Model(HiGHS.Optimizer) -# set_silent(model) -# @variable(model, x >= 0) -# @variable(model, 0 <= y <= 3) -# @objective(model, Min, 12x + 20y) -# @constraint(model, c1, 6x + 8y >= 100) -# @constraint(model, c2, 7x + 12y >= 120) -# optimize!(model) -# open("model.log", "w") do io -# print(io, solution_summary(model; verbose = true)) -# return -# end -# ``` - -# Saving the problem in `model.jl` and calling from the command line results in: -# ``` -# $ time julia model.jl -# 15.78s user 0.48s system 100% cpu 16.173 total -# ``` -# Clearly, 16 seconds is a large overhead to pay for solving this trivial model. -# However, the compilation latency is independent on the problem size, and so 16 -# seconds of additional overhead may be tolerable for larger models that take -# minutes or hours to solve. - -# In cases where the compilation latency is intolerable, JuMP is compatible with -# the [PackageCompiler.jl](https://julialang.github.io/PackageCompiler.jl/dev/) -# package, which makes it easy to generate a custom _sysimage_ (a binary -# extension to Julia that caches compiled code) that dramatically reduces the -# compilation latency. A custom image for our problem can be created as follows: -# ```julia -# using PackageCompiler, Libdl -# PackageCompiler.create_sysimage( -# ["JuMP", "HiGHS"], -# sysimage_path = "customimage." * Libdl.dlext, -# precompile_execution_file = "model.jl", -# ) -# ``` -# When Julia is run with the custom image, the run time is now 0.7 seconds -# instead of 16: -# ``` -# $ time julia --sysimage customimage model.jl -# 0.68s user 0.22s system 153% cpu 0.587 total -# ``` -# Other performance tweaks, such as disabling bridges or using direct mode can -# reduce this time further. - -# !!! note -# `create_sysimage` only needs to be run once, and the same sysimage can be -# used--to a slight detriment of performance--even if we modify -# `model.jl` or run a different file. - # ## Use macros to build expressions # Use JuMP's macros (or [`add_to_expression!`](@ref)) to build expressions.