Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Improve performance of String names

Đang mở
  • Có gì không ổn?
#2,443 0 bình luận 1 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
35/100
Loại issue
Tái cấu trúc
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
julia
Lĩnh vực
performance

Hướng nghiên cứu

Bắt đầu với src/Utilities/model.jl, tại các định nghĩa lưu trữ String được liên kết trong issue, sau đó xem xét cách việc lấy và thiết lập tên làm lộ biểu diễn nội bộ. So sánh InlineStrings.jl và WeakRefStrings.jl với yêu cầu tránh các đối tượng được GC theo dõi có vòng đời dài, đồng thời vẫn duy trì khả năng tương thích với String. Công việc được xem là hoàn tất khi hiệu năng tên trong các mô hình lớn được cải thiện mà không thay đổi hành vi tên công khai, sau đó điều tra các solver wrapper bị ảnh hưởng.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
Julia
Star
506
Fork
103
Merge trung bình
1 ngày 1 giờ
Pull request đã merge (30 ngày)
9

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của jump-dev/MathOptInterface.jl

Tất cả issue của jump-dev/MathOptInterface.jl

Issue tương tự

Thêm issue về Julia

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.