Performance drawback with subtyping

[lmiq]

@Ronneesley

Thanks for you answer. But with type parameter I’ve only one type of Line at lines attribute. I need both, lines type A, B, etc.

If you only need a few types, you probably want something like

struct Picture
   lines :: Vector{Union{LineA,LineB}}
end

still that can come with performance problems, because if you define a method that acts on these types, and you dispatch on this vector at run time, the dynamic dispatch will have a performance penalty. If you have many types, probably you will need some of the ideas that were dicussed in these threads, because at the end they ended up in a discussion of exactly that problem:

Disabling allocations

Very interesting. Using a simple eval did the trick: abstract type Material end struct Material1 <: Material m :: Float64 end struct Material2 <: Material m :: Float64 end struct HitPoint{T <: Material} p :: Float64 r :: Float64 m :: T end # the hit function hit(p <: HitPoint) = p.r*p.p*p.m.m # generate functors for each type for T in subtypes(Material) eval(:((p::HitPoint{$T})() = p.r*p.p*p.m.m)) end # naive sum function hits(hitpoints) s = 0. for p in hitpoints s +=…

A related follow up is here:

Macro to write function with many conditionals

Great that that had been done. I will see if I understand that implementation.

(and I wrote a simple example here, but I have yet to write it in detail: https://m3g.github.io/JuliaCookBook.jl/stable/splitting/