performance hints about mathoptinterface.jl HOT 13 CLOSED

Send everything to the solver as a VectorAffineFuntion in Nonpositives/Zeros?

No, we'll be providing the same constraints to the solver as the user provided to us.

We can try:

addconstraints!(::SolverInstance,::Vector{F},::Vector{S})

The solver can build a sparse matrix based on this and give all the constraints to the solver at once. We'd normally have to call this function three times, once for each of LessThan, GreaterThan, and EqualTo. That's better than 100,000 times for a problem with 100,000 constraints.

from mathoptinterface.jl.

Actually can we just overload the broadcast syntax to intercept addconstraint!.(...)?

from mathoptinterface.jl.

similarly to addconstraints!, deleteconstraints! would be useful too

from mathoptinterface.jl.

I posted this comment in jump-dev/CPLEX.jl#139

For Xpress there is a 10x speed and memory difference between adding variables 1 by 1 and adding them in a batch.
https://gist.github.com/joaquimg/5dbaf83e7555b94d79f4d01f8ed53119

from mathoptinterface.jl.

I expect we'll have to put a bit of work into efficiently moving the data from the JuMP Instance to the SolverInstance, but we can already create all of the variables at once with the current interface. Adding constraints one-by-one is potentially more of a performance issue.

from mathoptinterface.jl.

Very similar result for constraints:
https://gist.github.com/joaquimg/68c67de76eea7adea0b9ab880c667dfc

from mathoptinterface.jl.

What are you planning to do with instance?

Send everything to the solver as a VectorAffineFuntion in Nonpositives/Zeros?

Otherwise, I can only see the solver having to figure out when to add everything, and then load is very important. Moreover, load and SolverInstance become a bit complex, since they will have to do some bookkeeping.

Any ideas?

from mathoptinterface.jl.

3 (actually once per Set + Function combination) times should be fine.
I like this proposal.

from mathoptinterface.jl.

This can also be used to pass in all bounds, integrality constraints, etc.

from mathoptinterface.jl.

yep!

from mathoptinterface.jl.

No, not really (JuliaLang/julia#22053 (comment)):

Overriding broadcast for particular functions should ordinarily not be done, and at most should be done as an optimization only. Because of fusion, it will never be possible to guarantee that broadcast(::typeof(f), ...) is called for a particular f.

Seems a bit flimsy.

from mathoptinterface.jl.

It's just called delete!. No objection to defining a method for deleting a vector of references.

from mathoptinterface.jl.

Closing because we don't seem to have needed this or made progress. We have all the plural methods, it's just up to JuMP to plumb them through.

from mathoptinterface.jl.