# Invalidations caused by FixedPointNumbers
**URL:** https://discourse.julialang.org/t/invalidations-caused-by-fixedpointnumbers/139232
**Category:** Internals & Design
**Tags:** question, package, mtk, fixedpointnumbers
**Created:** [September 6, 2026, 12:34pm UTC](https://discourse.julialang.org/t/invalidations-caused-by-fixedpointnumbers/139232 "2026-09-06T12:34:30Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@ufechner7](https://discourse.julialang.org/u/ufechner7)
#### Post date: [September 6, 2026, 12:34pm UTC](https://discourse.julialang.org/t/invalidations-caused-by-fixedpointnumbers/139232/1 "2026-09-06T12:34:30Z")
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](https://github.com/JuliaMath/FixedPointNumbers.jl/issues/331)
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](https://github.com/JuliaGeometry/GeometryBasics.jl/issues/284). Both issues must be fixed before loading GLMakie does not create long delays for MTK any more.
---
### Author:  [@Benny](https://discourse.julialang.org/u/Benny)
#### Post date: [September 6, 2026, 10:21pm UTC](https://discourse.julialang.org/t/invalidations-caused-by-fixedpointnumbers/139232/2 "2026-09-06T22:21:48Z")
Might be case 4 mentioned in [Type piracy · Aqua.jl](https://juliatesting.github.io/Aqua.jl/stable/piracies/), 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.