Improve performance of String names

[odow]

A common source of performance problems in JuMP and MathOptInterface are dealing with the String names of variables and constraints.

As a recent example, see #2426 and related issues/PRs.

The main place that Strings are stored is:

MathOptInterface.jl/src/Utilities/model.jl

Lines 27 to 31 in dcfb033

	var_to_name::Dict{MOI.VariableIndex,String}
	# If `nothing`, the dictionary hasn't been constructed yet.
	name_to_var::Union{Dict{String,MOI.VariableIndex},Nothing}
	con_to_name::Dict{MOI.ConstraintIndex,String}
	name_to_con::Union{Dict{String,MOI.ConstraintIndex},Nothing}

When building models with large (>10^5) numbers of variables and constraints, these dictionaries contain a large number of strings. Each String is a GC-tracked object, and it is long-lived, because we maintain these dictionaries throughout the lifetime of a Model. If CachingOptimizer is involved, there can also be multiple copies of the strings, for example, if we have a setup like Cache(Model, Bridge(Cache(Model, Solver))).

Lots of long-lived GC-tracked objects are bad for Julia's garbage collector.

Workaround

The main workaround at present is JuMP.set_string_names_on_creation(model, false), which does not pass string names from JuMP to the solver.

The downside of this workaround is that solvers and file writers cannot print or display useful names to the user.

• Document cost of named variables and constraints in Performance Tips JuMP.jl#2973
• Constraints with few terms are (relatively) slow JuMP.jl#2817

Potential approaches

We should try replacing the String storage with an alternative string type. Candidates are:

• https://github.com/JuliaStrings/InlineStrings.jl
• https://github.com/JuliaData/WeakRefStrings.jl

To ensure backwards compatibility, we should make sure that getting and setting these strings uses the original String type, so that the internal storage is hidden from the user.

It is okay to convert between string types, and to generate extra allocations if these new strings are short-lived objects. The real performance problem is long-lived GC-tracked objects.

Solvers

Many solver packages also store String names. If the changes to MOI are an improvement, we should investigate was to simplify name handling in the different solver wrappers.