IMO it would be useful if the printing for a Problem showed something like the total size of variables/constraints/etc. I suppose we don't really know that fully until the MOI level, but we could provide some kind of Convex.jl-level estimate by recursing the tree and counting things. In particular, I think these would be useful:
number of atoms: this can show if some scalar indexing produced 10k atoms or something
number of AbstractVariable objects: likewise, the number of variables should be relatively small, even if the size is large
number of constraint objects: same
sum of length over all variables (with 2x for complex ones): this is the total variable "volume"
sum of size over all constraint sets
sum of nnz for sparse constants found in the problem
sum of length for dense constants found in the problem. Too big here can indicate incorrect densification.
Base.summarysize for the whole problem: Flux does this, and it seems like a useful bit of info.
These would serve two purposes:
provide info to the user before solve-time about how big their problem is
provide information to notice/diagnose performance bugs
Ideally we could provide a relatively compact printing with this information.
IMO it would be useful if the printing for a
Problemshowed something like the total size of variables/constraints/etc. I suppose we don't really know that fully until the MOI level, but we could provide some kind of Convex.jl-level estimate by recursing the tree and counting things. In particular, I think these would be useful:lengthover all variables (with 2x for complex ones): this is the total variable "volume"sizeover all constraint setsnnzfor sparse constants found in the problemlengthfor dense constants found in the problem. Too big here can indicate incorrect densification.Base.summarysizefor the whole problem: Flux does this, and it seems like a useful bit of info.These would serve two purposes:
Ideally we could provide a relatively compact printing with this information.