Invalidations caused by FixedPointNumbers

Internals & Design
, , ,
1

The FixedPointNumbers package is causing many invalidations, even though it does not engage in type piracy. For details, see: Loading FixedPointNumbers invalidates ~7,700 precompiled method instances (7x slower first mtkcompile) · Issue #331 · JuliaMath/FixedPointNumbers.jl · GitHub

My question: What is causing these invalidations? Should that be fixed in Julia itself, or in FixedPointNumbers, or is there no way to fix it?

I encounter this problem mainly when using GLMakie, which depends on FixedPointNumbers.

UPDATE: GeometryBasics has a similar problem: Loading GeometryBasics invalidates ~11,000 precompiled method instances (7x slower first mtkcompile) · Issue #284 · JuliaGeometry/GeometryBasics.jl · GitHub. Both issues must be fixed before loading GLMakie does not create long delays for MTK any more.

2

Might be case 4 mentioned in Type piracy · Aqua.jl, not explained like the others though. I know of invalidations where additional methods violate a prior assumption of a function only having a few (defaulting to 3 according to ?Base.Experimental.@max_methods) methods when abstract types are inferred for inputs, but a cursory glance at methods(-, Tuple{Real}) shows 9 in Base, so I doubt that assumption was made.

Probably unimportant, but I don’t see how the Union{} type described in case 3 and mentioned in the issue is practically relevant when nobody can instantiate it and won’t instantiate empty Union{}-parametric types, that is these call signatures aren’t worth compiling in the first place.