Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Loading FixedPointNumbers invalidates ~7,700 precompiled method instances (7x slower first mtkcompile)

オープン
  • 何か問題がありますか？
#331 コメント 4 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
42/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
julia
領域
performance

調査の方向性

まず mwe.jl と SnoopCompile の invalidation 測定から始め、続いて src/fixed.jl、src/normed.jl、src/FixedPointNumbers.jl にある列挙されたメソッドを調べます。より狭いシグネチャやその他の変更を、7,708 件の invalidation と mtkcompile の実行時間に照らして比較し、その間に FixedPointNumbers の動作が正しいままであることを確認します。完了とは、リグレッションなしにロード時の影響を削減することです。

索引モデルが issue の本文から書いたものです。

説明

Summary

Loading FixedPointNumbers into a session that already has ModelingToolkit loaded invalidates
7,708 precompiled method instances and makes the first mtkcompile call take 23.59 s
instead of 0.04 s — a huge slowdown in a script that never uses a fixed-point number.

Most users meet this indirectly: ColorTypes/Colors depend on FixedPointNumbers, so any
Makie-based plotting next to ModelingToolkit pays this cost on the first model build.

MWE

# mwe.jl
using ModelingToolkit
using ModelingToolkit: t_nounits as t, D_nounits as D
if get(ENV, "LOAD_FPN", "0") == "1"
    @eval using FixedPointNumbers      # <-- the only difference
end
@variables x(t)=1.0 y(t)=0.0
@named sys = System([D(x) ~ y, D(y) ~ -x], t)
t0 = time(); mtkcompile(sys); println("mtkcompile: ", round(time()-t0, digits=2), " s")

(test) pkg> st
Status `~/test/Project.toml`
  [53c48c17] FixedPointNumbers v0.9.1
  [961ee093] ModelingToolkit v11.41.0

$ julia --startup-file=no --project=. mwe.jl
mtkcompile: 0,04 s

$ LOAD_FPN=1 julia --startup-file=no --project=. mwe.jl
mtkcompile: 23.59 s

As a control, loading a package of comparable size that does not add methods to Base
generics (using LaTeXStrings) leaves the time unchanged at 0.04 s, so this is not the
general cost of loading a package.

Attribution

using SnoopCompileCore
using ModelingToolkit
invs = @snoop_invalidations using FixedPointNumbers;
using SnoopCompile
length(uinvalidated(invs))   # 7708, from 15 culprit methods

Ranked by countchildren:

children method
14312 promote_rule(::Type{Fixed{T1,f1}}, ::Type{Fixed{T2,f2}}) where {T1,T2,f1,f2} — src/fixed.jl:199
3556 length(r::AbstractUnitRange{N}) where {T<:Unsigned, N<:Normed{T}} — src/normed.jl:304
3089 ceil(::Type{Ti}, x::Normed) where Ti<:Integer — src/normed.jl:277
1668 showarg(io::IO, a::Array{T}, toplevel) where T<:FixedPoint — src/FixedPointNumbers.jl:279
403 reduce_first(::typeof(Base.add_sum), x::FixedPoint) — src/FixedPointNumbers.jl:296
109 -(x::X) where X<:FixedPoint — src/FixedPointNumbers.jl:233

None of these are type piracy — every one is dispatching on a FixedPointNumbers type. The
cost seems to come from adding methods to widely-inferred Base generics (promote_rule,
length, ceil, convert), which discards inference results in already-loaded packages
that call those generics on non-concrete argument types.

Question

Is there room to narrow any of these signatures, or is this something that has to be fixed
on the consuming side (or in Base)? I am mostly filing this for the record, since the
measured impact is large and I could not find an existing issue about it. Happy to run
further measurements if that helps.

Versions

Julia 1.12.7 (Linux, x86_64), FixedPointNumbers 0.8.6, ModelingToolkit 11.17.0,
SnoopCompile 3.2.9.

主要言語
Julia
スター
95
フォーク
38
平均マージ
1日 7分
マージ済み PR（30日）
4

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

JuliaMath/FixedPointNumbers.jl のほかの issue

JuliaMath/FixedPointNumbers.jl の issue をすべて見る

似ている issue

Julia の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。