Does multihypo NamedTuple recipe dynamic dispatch?

[dehann]

Oh, btw, think the same thing might be happening with multihypo recipes: https://github.com/JuliaRobotics/IncrementalInference.jl/blob/40962b76cc03c55b49bfded871a7db60f0a0fd22/src/ExplicitDiscreteMarginalizations.jl#L227

Originally posted by @dehann in https://github.com/JuliaRobotics/IncrementalInference.jl/issues/1564#issuecomment-1185633151

[dehann]

Probably best to just change the recipe to a hard type.

[Affie]

Should also fix related:

https://github.com/JuliaRobotics/IncrementalInference.jl/blob/40962b76cc03c55b49bfded871a7db60f0a0fd22/src/services/EvalFactor.jl#L155-L157

[Affie]

and: https://github.com/JuliaRobotics/IncrementalInference.jl/blob/40962b76cc03c55b49bfded871a7db60f0a0fd22/src/services/EvalFactor.jl#L235-L237

[Affie]

(;certainidx, allelements, activehypo, mhidx)

That should actually be fine.

[dehann]

Okay, but let me just ocnfirm. A dispatch as function argument should only dispatch once, so all these cases above are fine. The problem is when a struct field has type

struct MyType1{T <: NamedTuple}
  x::T
end

Thats when its bad?

Obviously the forced abstract type will be bad:

struct MyType2
  x::NamedTuple
end

[Affie]

Yes I agree. The bad case is if the names are variable. The functions will compile a new method for each name.

[dehann]

Yes I agree. The bad case is if the names are variable.

So is this fine to use with good performance?

struct MyType1{T <: NamedTuple}
  x::T
end

[Affie]

It will be a tradeoff between compile time and runtime. Every new NamedTuple will require a new method to be compiled.

[Affie]

This tip is relevant here: https://docs.julialang.org/en/v1/manual/performance-tips/#The-dangers-of-abusing-multiple-dispatch-(aka,-more-on-types-with-values-as-parameters)

[dehann]

Agreed, thanks.

[dehann]

Changed this to a hard type HypoRecipe anyway:

• #1669