Invalidations issues

[ChrisRackauckas]

# From: https://timholy.github.io/SnoopCompile.jl/stable/snoopr/
using SnoopCompile
invalidations = @snoopr begin
    using DifferentialEquations

    function lorenz(du,u,p,t)
     du[1] = 10.0(u[2]-u[1])
     du[2] = u[1]*(28.0-u[3]) - u[2]
     du[3] = u[1]*u[2] - (8/3)*u[3]
    end
    u0 = [1.0;0.0;0.0]
    tspan = (0.0,100.0)
    prob = ODEProblem(lorenz,u0,tspan)
    alg = Rodas5()
    tinf = solve(prob,alg)
end;

trees = SnoopCompile.invalidation_trees(invalidations);

@show length(SnoopCompile.uinvalidated(invalidations)) # show total invalidations

show(trees[end]) # show the most invalidated method

# Count number of children (number of invalidations per invalidated method)
n_invalidations = map(trees) do methinvs
    SnoopCompile.countchildren(methinvs)
end

Flagged this repo with being high on the invalidations list.

julia> trees[end-3]
inserting reduce_empty(rf::InitialValues.AdjoinIdentity, ::Type{T}) where T in InitialValues at C:\Users\accou\.julia\packages\InitialValues\P5PLf\src\InitialValues.jl:316 invalidated:
   backedges: 1: superseding reduce_empty(op, ::Type{T}) where T in Base at reduce.jl:311 with MethodInstance for Base.reduce_empty(::Function, ::Type{Expr}) (2 children) 
              2: superseding reduce_empty(op, ::Type{T}) where T in Base at reduce.jl:311 with MethodInstance for Base.reduce_empty(::Function, ::Type{Pkg.Resolve.FieldValue}) (21 children)
              3: superseding reduce_empty(op, ::Type{T}) where T in Base at reduce.jl:311 with MethodInstance for Base.reduce_empty(::Function, ::Type{VersionNumber}) (21 children)
              4: superseding reduce_empty(op, ::Type{T}) where T in Base at reduce.jl:311 with MethodInstance for Base.reduce_empty(::Function, ::Type{Int64}) (107 children)
   6 mt_cache

Can that overload be removed?

[tkf]

As I have raised in the very early point in the invalidation whack-a-mole (e.g., JuliaLang/www.julialang.org#794 (comment)) I am very wary of where this is going. A non-negligible amount of patches for fixing the invalidations seem to work against constructing extensible abstraction. This is why I'm not interested in the invalidation hunting at least in its naive form. (I am interested in coming up with patterns for extensible, composable, and well-formalized interface and solving the invalidation problem by construction. But I haven't had time to explore this yet.) So, even though I do enjoy the effect of fast startup thanks to the effort people put into this, I have no intention of joining the invalidation whack-a-mole myself.

That said, I do not want to get in the way of other people who wants to treat the symptom with today's technology. Furthermore, this particular instance of invalidation is due to (possibly) unused one-linear that I wasn't sure if it was a good idea:

InitialValues.jl/src/InitialValues.jl

Lines 314 to 316 in 9f6edf1

	# Not used in Transducers.jl ATM but it is probably a reasonable thing
	# to support (see, e.g., `Base.BottomRF`):
	Base.reduce_empty(rf::AdjoinIdentity, ::Type{T}) where {T} = Base.reduce_empty(rf.op, T)

So, I am OK with try removing this and see if other JuliaFolds packages can function without it.

[ChrisRackauckas]

Thanks!