Dramatic performance change by adding additional unused method

[lmiq]

I think that is what it is, effectively, if you follow that pattern. You could also parameterize more loosely, like:

struct Mother{T,S,M,PV}
    label::String
    shape::S             # Reference to the actual shape
    material::M                  # Reference to material
    daughters::Vector{PV} 
end

which will allow the types to be concrete, or go for a completely different layout to allow the Mother type to be simpler yet concrete. For instance, if instead of the actual Material as a field you have a label for the material type (as an integer, for instance, to enumerate the materials).

There are some threads discussing this type of pattern:

Union splitting vs C++

This is a continuation from this thread: Performance drawback with subtyping - #31 by paulmelis Here we have two codes, which compute someting simple (the sum of the values of a field of a type in an array of mixed types of objects). Typical case where it is hard to be type-stable and avoid run-time dispatch. With 2 different types in the list of types, union splitting kicks in in Julia and the code is fast. With more (in the present example 5 types), it does not. In the C++ code clearly it do…

Performance drawback with subtyping

Try writing paint2 like this: function paint2(p::Picture) s = 0. for l in p.lines if l isa LineA s += paint(l::LineA) else s += paint(l::LineB) end end s end Does that improve performance?

I am not sure if there is an “ideal” solution (in Julia or other languages). The default performance of what people usually implement in C++ seems to be faster than straightforward Julia implementation of the same thing, but there are a lot of nuances and possibilities which are discussed there.

@DNF

This is a syntax error for me. Perhaps you meant

Yes, thanks, I have to rationalize why these things are not equivalent at some point to remember which is the one that works.