Improve performance of String names
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 35/100
- Issue 类型
- 重构
- 描述清晰度
- 基本清楚
- 活跃度
- 停滞
- 技术栈
- julia
- 领域
- performance
调研方向
从 src/Utilities/model.jl 中 issue 所链接的 String 存储定义开始，然后检查获取和设置名称的方式如何暴露内部表示。将 InlineStrings.jl 和 WeakRefStrings.jl 与避免长期存活且受 GC 跟踪的对象、同时保持 String 兼容性的要求进行比较。完成的标准是在不改变公开名称行为的情况下改善大型模型中的名称性能，随后调查受影响的 solver wrapper。
由索引模型根据 Issue 内容生成。
描述
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:
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.
- 主要语言
- Julia
- 星标
- 506
- 派生
- 103
- 平均合并
- 1 天 10 分钟
- 30 天内合并 PR
- 12
环境准备
这个项目没有提供开发容器、Dockerfile 或贡献指南，环境需要你自己搭建：先看它的 README，通用步骤见我们的新手贡献指南。
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
jump-dev/MathOptInterface.jl 的其他 Issue
-
[Bridges] MultirowChange in set_map.jl drops zero coefficients可能已有人在做 @odow 于 6 天前认领。 未关闭
jump-dev/MathOptInterface.jl#3106 · 2 条评论 · 已指派 1 人 ·
维护者通常 1 天内回复
-
Precision loss in Hessian computation可能已有人在做 @blegat 于 6 天前认领。 未关闭
难度 5/5 一周以上 新手友好度 15/100
jump-dev/MathOptInterface.jl#3104 · 11 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 35/100
jump-dev/MathOptInterface.jl#2986 · 3 条评论 ·
维护者通常 1 天内回复
-
难度 5/5 一周以上 新手友好度 25/100
jump-dev/MathOptInterface.jl#2969 · 2 条评论 · 1 个 reaction ·
维护者通常 1 天内回复
-
Type: Set Request
难度 5/5 一周以上 新手友好度 35/100
jump-dev/MathOptInterface.jl#2904 · 15 条评论 · 7 个 reaction ·
维护者通常 1 天内回复
查看 jump-dev/MathOptInterface.jl 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 74/100
OpenSourceAWE/SymbolicAWEModels.jl#431 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
EnzymeAD/Reactant.jl#3549 ·
维护者通常 1 天内回复
-
bug
难度 2/5 1-3 小时 新手友好度 75/100
-
bug help wanted
难度 2/5 1-3 小时 新手友好度 68/100
JuliaGeometry/Meshes.jl#1469 ·
维护者通常 1 天内回复