-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Time to first execution (TTFX) #120
Comments
Just as a reference, there is a big discussion about this in this issue jump-dev/MathOptInterface.jl#2226. They have made some precompilation statements for some solvers as a test. Maybe you could use some of the information even if not using the MOI interface. |
I made an initial attempt at this in pg/precompile, just using SnoopPrecompile on the solver's direct interface (i.e. not via MOI). It doesn't seem to have made any improvement at all, even on julia v1.9, but I think I must be doing some really basic thing wrong. I will revisit once I have had a closer look at the issue suggested by @guilhermebodin. |
How about __precompile__()
.
.
.
precompile(Tuple{Type{Solver{Float64}}})
precompile(Tuple{typeof(Core.kwcall), NamedTuple{(:verbose,), Tuple{Bool}}, Type{Settings{Float64}}})
precompile(Tuple{typeof(setup!), Solver{Float64}, SparseArrays.SparseMatrixCSC{Float64, Int64}, Array{Float64, 1}, SparseArrays.SparseMatrixCSC{Float64, Int64}, Array{Float64, 1}, Array{SupportedCone, 1}, Settings{Float64}})
precompile(Tuple{typeof(solve!), Solver{Float64}})
|
That also doesn't seem to improve things, and |
May be you should add things like Base.precompile(Tuple{typeof(computeCL!), Vector{sCL{Float64}}, Vector{Status}, Problem{Float64}, Settings{Float64}}) where the I do not know what are the working horses of your functions. |
jump-dev/JuMP.jl#122 has TTFX for the native solver interface (i.e. not MOI / JuMP) down to < 25ms. Package load times are also now a lot shorter. NB: testing described on that PR is all on julia 1.9.0-rc1 and the master branches of MOI and JuMP. |
This should be fixed in v0.5.0, released today. I will close the issue but please reopen if there is still a problem. For greatest improvement in load times you need julia v1.9 or higher. It will still work with earlier versions though. |
on Julia 1.9 rc1, there still needs 13 seconds for first run, and 0.3 seconds for second run, for one of my dataset.
I find that the package
EfficientFrontier
cut down from 7.89 seconds ( Julia 1.8.5) to 0.13 seconds (1.9 rc1). Lines likeBase.precompile(Tuple{...})
may be helpfulThe text was updated successfully, but these errors were encountered: