Conversation
|
Alternatively, shouldn't |
|
We'd still have to create the 97 arrays, but I'll take a look. |
Indeed but we were already allocating one array per type before MOI v0.9.21. There is a tradeoff there between the added |
69667d2 to
fe041f7
Compare
|
I took a look. it's actually not about the cost of creating the objects. It's the cost of inferring them. If every function-set could exist, the compiler needs to make sure that every function that could be called exists. Having This PR:
|
|
So having nothing avoids the |
|
Editing the StructOfConstraints might get a bit messy. I'd prefer to do it in a separate PR. I think its an and instead of an or, and that we would have this change regardless. The biggest win comes from dropping the 97 combinations to a few. I don't think going from 6 function types to less is going to make as much of a difference. |
|
Now we're getting somewhere: |
|
Interestingly, this PR doesn't affect how many times we enter inference. It's 41 on this PR and on using SnoopCompile
tinf = @snoopi_deep example_diet(Clp.Optimizer, true)
itrigs = inference_triggers(tinf)
mtrigs = accumulate_by_source(Method, itrigs)
julia> length(mtrigs)
41 |
|
@blegat objections to merging? It would be good to get into |
|
Remove the Much better than before. |

Part of #1313
Calling
MOIU.Model{Float64}()does a lot of work. It has to create 97 differentCleverDicts to store all the constraints in! Even though most users only use a small fraction of the possible constraint types.This PR uses a small
Union{Nothing,X}to avoid creating the dictionaries, instead it lazily creates them on the first call toadd_constraint.Before
After