Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Improve performance of String names

Ouverte
  • Quelque chose ne va pas ?
#2,443 0 commentaires 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Refactorisation
Clarté
Plutôt claire
Activité
À l'abandon
Stack technique
julia
Domaine
performance

Piste de recherche

Commencez par src/Utilities/model.jl, au niveau des définitions de stockage de String liées dans l’issue, puis examinez comment la lecture et la définition des noms exposent la représentation interne. Comparez InlineStrings.jl et WeakRefStrings.jl à l’exigence d’éviter les objets suivis par le GC dont la durée de vie est longue, tout en préservant la compatibilité avec String. Le travail est considéré comme terminé lorsque les performances des noms dans les grands modèles sont améliorées sans modifier le comportement public des noms, puis qu’une étude des wrappers de solveur concernés a été menée.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Status: help wanted Type: Performance

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 https://github.com/jump-dev/MathOptInterface.jl/pull/2426 and related issues/PRs.

The main place that Strings are stored is:

https://github.com/jump-dev/MathOptInterface.jl/blob/dcfb03311bb6afc10a36e7967cdd9aecb706241c/src/Utilities/model.jl#L27-L31

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.

Potential approaches

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

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.

Langage dominant
Julia
Étoiles
506
Forks
103
Merge moyen
1 j 1 h
PR mergées (30 j)
9

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de jump-dev/MathOptInterface.jl

Toutes les issues de jump-dev/MathOptInterface.jl

Issues similaires

Plus d'issues Julia

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.