# Any performance issues with multiple dispatch?

**URL:** <https://discourse.julialang.org/t/any-performance-issues-with-multiple-dispatch/55468>\
**Category:** New to Julia\
**Created:** [February 17, 2021, 3:55pm UTC](https://discourse.julialang.org/t/any-performance-issues-with-multiple-dispatch/55468 "2021-02-17T15:55:52Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ribeiro](https://avatars.discourse-cdn.com/v4/letter/r/d9b06d/32.png) [@Ribeiro](https://discourse.julialang.org/u/Ribeiro)\
**Post date:** [February 17, 2021, 3:55pm UTC](https://discourse.julialang.org/t/any-performance-issues-with-multiple-dispatch/55468/1 "2021-02-17T15:55:52Z")

</div>

Hi!  
I have some functions in a loop that get called a huge number of times. Some of them have two different forms, one when my elements are triangles and on when they are quads. Normally, I’d write two different for loops, check if I have quads or tris before entering the for loop, and then call the Tri function in one of them and the Quad in the other one. This would avoid an if condition to check which function to call for every loop iteration.  
With multiple dispatch, I can have the same function written twice, once with 3 inputs and once with 4 inputs. No if statement, no two loops.  
I haven’t seen a performance penalty from doing that, but maybe I’m not testing enough. Are there no performance disadvantages in doing what I described? Isn’t the code effectively performing an if statement to choose the right function?  
Thanks a lot!

---

<div class="post-metadata">

**Author:** ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)\
**Post date:** [February 17, 2021, 4:02pm UTC](https://discourse.julialang.org/t/any-performance-issues-with-multiple-dispatch/55468/2 "2021-02-17T16:02:15Z")

</div>

This depends on what your data is. If you are dealing with something like a `Vector{Quad}` or `Vector{Tri}`, than multiple dispatch is zero cost. If you have a `Vector{Union{Tri,Quad}}`, then Julia will probably just put an if statement in. If you have a `Vector{Shape}` (where `Quad`, `Tri` are subtypes of shape), then multiple dispatch will probably be slower as it will be doing dispatch at runtime.

---

<div class="post-metadata">

**Author:** ![Ribeiro](https://avatars.discourse-cdn.com/v4/letter/r/d9b06d/32.png) [@Ribeiro](https://discourse.julialang.org/u/Ribeiro)\
**Post date:** [February 17, 2021, 4:15pm UTC](https://discourse.julialang.org/t/any-performance-issues-with-multiple-dispatch/55468/3 "2021-02-17T16:15:49Z")

</div>

> [@Oscar\_Smith](#):
>
> ch is zero cost. If you have a `Vector{Union{Tri,Quad}}` , then Julia will probably just put an if statement in. If you have a `Vector{Shape}` (where `Quad` , `Tri` are subtypes of shape), then multiple d

I see. Makes sense. My vector is either all quads or all tris, so Julia is figuring it out from there. Great!  
Thanks a lot for the answer!

---

<div class="post-metadata">

**Author:** ![oxinabox](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oxinabox/32/206603_2.png) [@oxinabox](https://discourse.julialang.org/u/oxinabox)\
**Post date:** [February 17, 2021, 4:21pm UTC](https://discourse.julialang.org/t/any-performance-issues-with-multiple-dispatch/55468/4 "2021-02-17T16:21:28Z")

</div>

To be clear this is not multiple dispatch problems.  
It is also a problem for single dispatch.  
Its a dynamic dispatch vs static dispatch problem.  
Does it need to resolve the dispatch are runtime, or can it work it out at compile time.

This is incontrast to some other languages with multiple dispatch where using multiple dispatch is strictly slower than single dispatch.  
This has historically given multiple dispatch a bad reputation.  
But Julia has done the hard thing, and worked out how to make multiple dispatch fast.

---

<div class="post-metadata">

**Author:** ![stevengj](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/stevengj/32/71_2.png) [@stevengj](https://discourse.julialang.org/u/stevengj)\
**Post date:** [February 17, 2021, 4:29pm UTC](https://discourse.julialang.org/t/any-performance-issues-with-multiple-dispatch/55468/5 "2021-02-17T16:29:34Z")

</div>

> [@oxinabox](#):
>
> It is also a problem for single dispatch.  
> Its a dynamic dispatch vs static dispatch problem.

That being said, the costs of dynamic dispatch might be higher for multiple dispatch, since single dispatch can use [vtables](https://en.wikipedia.org/wiki/Virtual_method_table). Fortunately, Julia was designed from the beginning to have semantics that enable “devirtualization” (static dispatch) in typical performance-critical code, whereas this has to be retrofitted onto C++.

---

<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:** [February 17, 2021, 5:18pm UTC](https://discourse.julialang.org/t/any-performance-issues-with-multiple-dispatch/55468/6 "2021-02-17T17:18:49Z")

</div>

You will reach a performance penalty if the number of types increase, which can be dealt with manual splitting. There are some threads discussing that, and solutions, for example:

> [@Performance problems when dealing with deliberately type-unstable code. How to use type knowledge better?](https://discourse.julialang.org/t/performance-problems-when-dealing-with-deliberately-type-unstable-code-how-to-use-type-knowledge-better/52535):
>
> I have a problem that crops up again and again, which relates to the use of different concrete types in situations where I can’t possibly establish type stability. Here’s a contrived example: There are three different subtypes, and I have a vector of two of them, which is parameterized with the abstract type. Therefore, the compiler doesn’t know the return type of the function get\_value. But I as the programmer do know that it will always be Float64, because I have set up the logic that way. How…