# Dramatic performance change by adding additional unused method

**URL:** https://discourse.julialang.org/t/dramatic-performance-change-by-adding-additional-unused-method/71771
**Category:** Performance
**Created:** [November 19, 2021, 11:56am UTC](https://discourse.julialang.org/t/dramatic-performance-change-by-adding-additional-unused-method/71771 "2021-11-19T11:56:03Z")
**Posts on this page:** 1
**Showing post:** 13

<div class="post-metadata">

### Author: ![lmiq](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/lmiq/32/18314_2.png) [@lmiq](https://discourse.julialang.org/u/lmiq)
#### Post date: [November 19, 2021, 2:15pm UTC](https://discourse.julialang.org/t/dramatic-performance-change-by-adding-additional-unused-method/71771/13 "2021-11-19T14:15:16Z")

</div>

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

```julia
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++](https://discourse.julialang.org/t/union-splitting-vs-c/61772):
>
> This is a continuation from this thread: [Performance drawback with subtyping - #31 by paulmelis](https://discourse.julialang.org/t/performance-drawback-with-subtyping/51939/31) 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](https://discourse.julialang.org/t/performance-drawback-with-subtyping/51939/9):
>
> 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.

---

_[View the full topic](https://discourse.julialang.org/t/dramatic-performance-change-by-adding-additional-unused-method/71771)._