Implement copy_to

[odow]

An efficient implementation of MOI.copy_to is needed when JuMP is used in AUTOMATIC mode.

See jump-dev/Gurobi.jl#188 (comment).

[blegat]

Not that a copy_to is only used if the layer structure is
Cache-LQOI
or
Cache-Bridges-Cache-LQOI
To have a similar speedup with
Cache-Bridges-LQOI
we can build the matrix with the allocate-load API like SCS (requires jump-dev/MathOptInterface.jl#523)

[ndinsmore]

Would there be any benefit to adding a few basic solver traits as part of this? I am thinking of something that signifies columnwise(Clp) vs rowwise(gurobi) data structures.

I haven't gotten a chance to run the benchmark yet but I would imagine that for Clp it would be much faster to add "empty" constraints, then add the coefficients when you add the variable (column)

[odow]

Would there be any benefit to adding a few basic solver traits as part of this? I am thinking of something that signifies columnwise(Clp) vs rowwise(gurobi) data structures.

I think this is an argument for solver-specific implementations.

Basically, we need to decide the trade-off between

• code duplication (CPLEX and Gurobi are very similar)
• code complexity dealing with different types of backends.

We also have to consider that LQOI is another level of abstraction between JuMP and the solver.

I'm coming round to the idea that solver-specific implementations (with duplication) are worthwhile. Particularly so now that MOI is more settled.

[joaquimg]

I dont think LQOI need to be another layer.
It could be part of MOIU.
I am against code duplication.
Unless its proven that code
Is significantly different.

[ndinsmore]

I actually find the LQOI interface much easier to read. If there was a way with helper functions or macros to make MOI more friendly that would be awesome and a maybe a reason to sunset LQOI.

That being said the changes to LQOI I have made recently:
#96
Has really moved the performance bottleneck onto the expression Dicts in LQOI and OrderedDicts in MOI.