# Inlining and function boundaries

**URL:** <https://discourse.julialang.org/t/inlining-and-function-boundaries/41686>\
**Category:** Performance\
**Created:** [June 18, 2020, 6:35pm UTC](https://discourse.julialang.org/t/inlining-and-function-boundaries/41686 "2020-06-18T18:35:42Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Kiuhnm\_Mnhuik](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kiuhnm_mnhuik/32/7572_2.png) [@Kiuhnm\_Mnhuik](https://discourse.julialang.org/u/Kiuhnm_Mnhuik)\
**Post date:** [June 18, 2020, 6:35pm UTC](https://discourse.julialang.org/t/inlining-and-function-boundaries/41686/1 "2020-06-18T18:35:42Z")

</div>

I read that inlining, by removing function boundaries, may cause type instability. Is this true? This doesn’t seem too hard to fix, but I’m not familiar with Julia internals.

---

<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:** [June 18, 2020, 7:45pm UTC](https://discourse.julialang.org/t/inlining-and-function-boundaries/41686/2 "2020-06-18T19:45:42Z")

</div>

> [@Kiuhnm\_Mnhuik](#):
>
> I read that inlining, by removing function boundaries, may cause type instability.

Only if the call site is _already_ type-unstable. If you have code where the types of variables are correctly inferred, then inlining function calls on these type-inferred variables is fine.

If you have a call to `f(x)` at a call site where `x` is _not_ type-inferred (e.g. `x` is type-unstable), then the call `f(x)` must dynamically dispatch to the correct compiled version of `f` depending on the type of `x`, but thereafter can be fast because it runs a type-specialized version of `f`. In this case, inlining `f` may worsen performance because it removes the type-specialization for particular types of `x`.

In practice, however, you would typically only want to inline relatively cheap functions anyway, and in this case you would need the call-site to be type-stable to avoid the dynamic-dispatch overhead even if you weren’t inlining.

So I don’t think this is a big problem — the focus should be on making the call-site type-stable, not on optimizing inlining of type-unstable calls.